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 in
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 invocatio
* 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 c
On Mon, 2020-08-03 at 17:26 +0100, Daniel P. Berrangé wrote:
> On Mon, Aug 03, 2020 at 05:34:47PM +0200, Hans de Goede wrote:
> > Hi,
> >
> > On 8/3/20 5:27 PM, Daniel P. Berrangé wrote:
> > > On Mon, Aug 03, 2020 at 05:01:18PM +0200, Florian Weimer wrote:
> > > > * Daniel P. Berrangé:
> > > >
>
On Mon, Aug 03, 2020 at 05:40:42PM +0200, Florian Weimer wrote:
> * Daniel P. Berrangé:
>
> > If I run LD_DEBUG=all on a build /with/ LTO, there are no symbol lookups
> > at all for qemuProcessStartManagedPRDaemon. It looks very much like the
> > call was resolved and bound at link time when built
On Mon, Aug 03, 2020 at 05:34:47PM +0200, Hans de Goede wrote:
> Hi,
>
> On 8/3/20 5:27 PM, Daniel P. Berrangé wrote:
> > On Mon, Aug 03, 2020 at 05:01:18PM +0200, Florian Weimer wrote:
> > > * Daniel P. Berrangé:
> > >
> > > > Disabling LTO in the RPM spec confirms this and makes things pass
> >
* Daniel P. Berrangé:
> If I run LD_DEBUG=all on a build /with/ LTO, there are no symbol lookups
> at all for qemuProcessStartManagedPRDaemon. It looks very much like the
> call was resolved and bound at link time when built with LTO.
It's possible that the symbol extraction logic is confused by
Hi,
On 8/3/20 5:27 PM, Daniel P. Berrangé wrote:
On Mon, Aug 03, 2020 at 05:01:18PM +0200, Florian Weimer wrote:
* Daniel P. Berrangé:
Disabling LTO in the RPM spec confirms this and makes things pass
again. Hacking the makefiles to remove the -fno-lto option when
building the test suite bina
On Mon, Aug 03, 2020 at 05:01:18PM +0200, Florian Weimer wrote:
> * Daniel P. Berrangé:
>
> > Disabling LTO in the RPM spec confirms this and makes things pass
> > again. Hacking the makefiles to remove the -fno-lto option when
> > building the test suite binaries also fixes things.
> >
> > I don'
On Mon, Aug 03, 2020 at 05:01:18PM +0200, Florian Weimer wrote:
> * Daniel P. Berrangé:
>
> > Disabling LTO in the RPM spec confirms this and makes things pass
> > again. Hacking the makefiles to remove the -fno-lto option when
> > building the test suite binaries also fixes things.
> >
> > I don
* Daniel P. Berrangé:
> Disabling LTO in the RPM spec confirms this and makes things pass
> again. Hacking the makefiles to remove the -fno-lto option when
> building the test suite binaries also fixes things.
>
> I don't see any mention of LD_PRELOAD being impacted by LTO in the
> Fedora feature
I'm trying to understand failures in the libvirt test suite since the
Fedora rawhide mass rebuild.
Our test suite makes extensive use of mocking to replace functions in
the library being tested. We do this either by loading a LD_PRELOAD,
or by having the test program define a symbol with the same
12 matches
Mail list logo
