https://bugs.kde.org/show_bug.cgi?id=338252
--- Comment #18 from Philippe Waroquiers <philippe.waroqui...@skynet.be> ---
(In reply to Дилян Палаузов from comment #16)
> People either want to compile everything with LTO, or nothing with LTO, or
> they don't know about LTO.
Humph, that looks like a very general statement about all people in the
world :).
There exist at least one person (me) that knows about LTO and that does
not want to compile everything with LTO, but want to compile a few
things with LTO :).
And I highly suspect that a lot (many ? all ?) distribution packagers
also do not configure all the packages the same way.
> So people willing LTO either know the aforementioned ways to compile with
> LTO, or they do not insist of having LTO.
Launching a valgrind configure/make with CFLAGS containing -flto
fails for various mysterious reasons (see below).
The attached patch is an approach to solve these problems,
obtained after several other approaches failed (in particular to solve
the asm related problems).
>
> In fact valgrind and php are the only software I am aware of that doesn't
> work with LTO, php ignoring LDFLAGS from config.site and postgresql ignoring
> CFLAGS from config.site, and all the rest is working with both the autoconf
> principles and with LTO.
The first problem to solve (as you saw) is the genoffset problem.
As genoffset already had specific compiler options, I just slightly extended
the current approach. => problem solved.
I prefer to do the minimal change in this tricky area : I have no idea what
could be the impact of more heavily changing the way genoffset is compiled.
So, just compiling it with the same flags as today is the safest approach:
if --enable-lto is not used, then it just works as of today.
I then tried hard to solve the linking problems with VG_MINIMAL_SETJMP.
Once it was solved, I had to solve the problem of another undefined reference
(_start).
These were solved by adding a pragma to push the option -fno-lto
for the problematic files.
With these fixes, I obtained something working on my 'main' distro (debian),
but with a very strange warning, something like:
a plugin is needed to handle lto objects
And of course, my toolchain is configured with plugin support !
So this warning is completely mysterious/not understandable.
But as the resulting valgrind was working, I just ignored the warning.
I then tested on another distro (fedora+s390x)
There the build stopped with an error message 'invalid option -fno-lto'
(while -flto is properly supported). So, yet another mystery.
Various other trials to fix the problem resulted in gcc-ar/ar core dumping,
compilation failing, or resulting valgrind not working.
So, another bunch of mysteries. I even tried to debug gcc-ar/ar, but could
not make any sense of what I saw.
Finally, I obtained the attached patch, that I have validated on 4
distributions,
with 4 different gcc versions.
As I understand, your opinion is that the way valgrind autoconf/automake is
done
is 'not clean', as e.g. it hardcodes some compilation options (-O2 and
similar).
I am not an autoconf/automake expert, so I cannot really judge, and for sure
I do not have the time/knowledge to clean all that up.
So, in summary:
* as I understand, a clean solution would imply to heavily rework valgrind
build system.
* Valgrind build system also supports build a primary and secondary arch.
Not too sure that this is very usual/supported out of the box when
using CFLAGS on the command line (flags must be different for primary and
secondary arch).
So, that might make a clean solution more complex to obtain.
* even if --enable-lto option is not a clean solution, at least it allows to
build with lto if desired.
Note that as far as I can see, several other packages have such an option
--enable-lto. See e.g. https://forums.gentoo.org/viewtopic-t-1052716.html
Sorry for not being able to do things better in this area, I guess we will
need a real expert for this.
In the meantime, if the patch is deemed reasonable enough, I will push it, as
at
least it allows to have an lto compiled valgrind, and points at what
has to be compiled 'specially' if someone wants to do a cleaner build system.
--
You are receiving this mail because:
You are watching all bug changes.
