[PATCH v2] Improve building with LTO

[Dmitry V. Levin]

Hi Mark,

On Tue, Nov 09, 2021 at 12:18:31AM +0100, Mark Wielaard wrote:
> Hi Dmitry,
> 
> On Mon, Nov 08, 2021 at 01:02:28PM +0300, Dmitry V. Levin wrote:
> > > Thanks. This patch was indeed one reason I kept postponing the release,
> > > because I didn't have have time to properly review it.
> > > 
> > > Which gcc versions have you tried this against (with/without -flto?)
> > 
> > I tested with gcc10 and gcc11.
> > I could try older versions, although I didn't feel that necessary.
> 
> I also did try with gcc 4.8 and gcc 8 (both without lto though).
> 
> > https://sourceware.org/bugzilla/show_bug.cgi?id=27367 will likely strike
> > those who would build elfutils with -flto using gcc11+.
> 
> But only if they use -ffat-lto-objects (which isn't the default)?

Yes, but those who build elfutils with -flto are likely using
-ffat-lto-objects if they build static libraries.

> Did you see and try the patch I proposed? Do you think we should include
> it? I would like someone else to check/try it.

Yes, the patch makes run-readelf-self.sh test pass, and causes no visible
regressions.  I'm not familiar with that code to review the patch, but
I'm happy to use it anyway.

> > > does also impact symbol versioning for non-lto builds, so I am still a
> > > little hesitant. I'll try to do some tests to make sure things look ok
> > > with different gcc versions.
> > 
> > What do you mean by "it does also impact symbol versioning for non-lto
> > builds"?  The code for non-lto builds changes, but the versioning
> > should remain the same, shouldn't it?
> 
> I meant I am paranoid :) We are using slightly different asm or an
> attribute to mark the symbol version than we did before. But I double
> checked the exported versioned symbols with and without this patch on
> different gcc versions and they look fine.
> 
> So I did just now push this patch.

Thanks!


-- 
ldv