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
