Control: tag -1 - moreinfo Control: clone -1 -2 Control: retitle -1 gcc-7: Discarded unused code leaves entry on .gnu.version_r Control: reassign -1 gcc-7 Control: retitle -2 network-manager: Unused code causes gcc to leave unused version reference Control: reassign -2 network-manager
Hi! On Sun, 2017-09-10 at 22:12:13 +0100, Dimitri John Ledkov wrote: > On 10 September 2017 at 15:03, Guillem Jover <guil...@debian.org> wrote: > > On Thu, 2017-09-07 at 16:16:49 +0100, Dimitri John Ledkov wrote: > >> Package: dpkg > >> Version: 1.18.24 > >> Severity: important > > > >> I am attaching the objdump to this bug report. In that log, one can > >> see that the highest symbol referenced by Dynamic symbol table is for > >> GLIBC_2.17 which is the dependency dpkg-shlibs generates. > >> > >> However, in the `Version References' section, one can see that > >> GLIBC_2.25 is required. > >> > >> The net result is that libc6 (>= 2.17) is generated, instead of the > >> required libc6 (>= 2.25). > >> > >> The binaries are not executable when e.g. 2.24 glibc is installed and > >> fail like so: > >> > >> # ldd /usr/sbin/NetworkManager > >> /usr/sbin/NetworkManager: /lib/x86_64-linux-gnu/libc.so.6: version > >> `GLIBC_2.25' not found (required by /usr/sbin/NetworkManager) > >> > >> I am not sure how glibc managed to generate a Version reference, > >> without using any of the dynamic symbols from 2.25. > > > > I've built and checked the resulting binary, by objdump'ing everything > > I could think of, and I was unable to see why the version reference > > had been picked up. > > > >> Reading the code, it seems like maybe dpkg-shlibdeps needs to grow the > >> ability to parse "Version References" section of the objdump and use > >> version symbols referenced there to bump up requirements just like > >> dynamic symbols do? > > > > Before doing that I'd like to first understand why that is the case, if > > it's expected and not a bug in the toolchain or similar. > > That is a very reasonable question. Given that the version dep is 2.25 > I went through the glibc abi lists to see what was new in 2.25. > A few things from those are referenced in the NetworkManager but > unused (e.g. makedev()) and thus did not gain a dep (e.g dropping that > function did not result in getting the ABI back lower). > However, in the partial embedded copy of systemd there is embeded > implementation of explicit_bzero if glibc does not provide one. > It seems that NetworkManager included the declaration check too in > their configure.ac such that with glibc 2.25+ explicit_bzero from libc > starts to be referenced. > However, in the end, none of the bits that NetworkManager actual use > hit the string_erase function and thus do not call explicit_bzero. > Thus it looks like compiler did compile / link usage of > explicit_bzero, and eventually dropped it, yet version info persistent > to the end binaries/libraries. > With the attached patch, builds of network-manager end up not having > GLIBC_2.25 version reference. Thanks for the investigation! When I also checked the new symbols in glibc, I also suspected that explicit_bzero was a very probable candidate, but it was not obvious why, simply from the glibc side. > Is this normal toolchain behaviour to not optimise out version > references, when all symbols are optimised out? > The code is crazy, but I would have expected optimised out things to > remove version references too. Yes, that looks like a bug to me, if the code gets removed then the versioned references should also be removed, otherwise we are unnecessarily demanded a version that is greater than it's really needed. Reassigning both to gcc-7 to get this fixed there (assuming this is not a binutils problem?), and to network-manager to workaround the issue for now. I'm not sure if gcc-6 is affected, if it is, please clone another one into that. Thanks, Guillem
