On Tue, 2020-08-04 at 13:16 +0100, Daniel P. Berrangé wrote:
On Tue, Aug 04, 2020 at 12:02:05PM +0200, Florian Weimer wrote:
> * Daniel P. Berrangé:
> > Taken from
https://koji.fedoraproject.org/koji/taskinfo?taskID=48525923
> Sorry, what would be more interesting is the linker
invocation. The
> build log does not show this, only the libtool invocation. We don't
> really know what kind of transformations libtool does in this case.
Upstream libvirt has just yesterday replaced use of autotools with
meson. I just tried a Fedora rawhide build of our new meson based
code and it succeeded with LTO.
Given this, I think I'm fine just disabling LTO in rawhide for the
current libvirt release, with the expectation we'll re-enable LTO
in ~1 month time when we import the meson based release of libvirt.
IOW lets not waste any more time debugging this LTO / LD_PRELOAD
problem with libvirt.
That works for me. If you haven't already committed the
change, please make a
quite note about the planned move to meson and reenablement of LTO at that point
so I don't dig any further when I review all the opted-out packages. I'm likely
to forget the decision by the time I'm reviewing the opt-outs.
> libtool is really not built for LTO, and it really should not be used on
> GNU systems. But I understand that this is not uncontroversial.
There's oooh so many problems with libtool we've hit over the years,
especially with it re-arranging order of compiler/linker flags, and
so I'm beyond ecstatic that we've finally thrown it away for libvirt
in favour of meson.
There may have been a time & place for libtool and autotools in
general, but that time has passed....
Yea, I find libtool amazingly painful and the
primary motivation for it has long
since become a minor issue rather than major one (seriously who cares about
dynamic linking on hpux, sco, irix, etc) anymore. But killing it I'm sure will
be difficult.
jeff