[Pkg-utopia-maintainers] Bug#874585: dpkg-shlibdeps: does not parse Version References

[Guillem Jover]

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 <guillem at 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