[forwarded from https://launchpad.net/bugs/1715641] test files at https://people.canonical.com/~doko/tmp/lp1715641.tar.xz feel free to call that a regression or behavior change ;) ... This is seen when building NetworkManager using ld 2.29 using glibc 2.26, the dpkg-shlibs tool not seeing a versioned dependency on a glibc 2.26 symbol, and then the packaging tools declaring NetworkManager be ready for use with glibc 2.24, and then the dynamic loader complaining with # 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) The behaviour change between ld 2.28 and ld 2.29 seems to be $ readelf -V NetworkManager-ld-2.28 | fgrep GLIBC_2.25 $ readelf -V NetworkManager-ld-2.29 | fgrep GLIBC_2.25 0x0170: Name: GLIBC_2.25 Flags: none Version: 11 $ readelf -V NetworkManager-gold-2.28 | fgrep GLIBC_2.25 000: 0 (*local*) 2 (GLIBC_2.25) d (CURL_GNUTLS_3) d (CURL_GNUTLS_3) 0x0010: Name: GLIBC_2.25 Flags: none Version: 2 $ readelf -V NetworkManager-gold-2.29 | fgrep GLIBC_2.25 000: 0 (*local*) 2 (GLIBC_2.25) d (CURL_GNUTLS_3) d (CURL_GNUTLS_3) 0x0010: Name: GLIBC_2.25 Flags: none Version: 2 $ objdump -T NetworkManager-ld-2.29|grep GLIBC_2.25 $ objdump -T NetworkManager-gold-2.29|grep GLIBC_2.25 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.25 __explicit_bzero_chk There is no behavior change in gold, and gold correctly marks the symbol as undefined. ld-2.28 otoh is able to detect that the symbol isn't used, doesn't emit a reference, but in 2.29 it keeps a reference in the .gnu.version_r section. Is this expected behavior? There is a bug in NetworkManager as well, as it defines a backup for the explicit_bzero function which is new in glibc 2.25, but it fails to define that for explicit_bzero_chk which is used when building with -D_FORTIFY_SOURCE.
seems to be not target specific
Is this against ld or gold? If it is against ld, please provide a testcase for ld, not for gold. link.sh uses gold, not ld.
it is against ld. forgot to reset the link script after generating the binaries with the four linker variants.
(In reply to Matthias Klose from comment #3) > it is against ld. forgot to reset the link script after generating the > binaries with the four linker variants. It doesn't work with ld: ld.bfd: warning: libpcre.so.3, needed by libglib-2.0.so.0, not found (try using -rpath or -rpath-link) ld.bfd: warning: libunistring.so.0, needed by libpsl.so.5, not found (try using -rpath or -rpath-link) ld.bfd: warning: librtmp.so.1, needed by libcurl-gnutls.so.4.4.0, not found (try using -rpath or -rpath-link) libglib-2.0.so.0: undefined reference to `pcre_fullinfo' libcurl-gnutls.so.4.4.0: undefined reference to `ldap_sasl_bind@OPENLDAP_2.4_2' libcurl-gnutls.so.4.4.0: undefined reference to `ldap_get_dn_ber@OPENLDAP_2.4_2' libcurl-gnutls.so.4.4.0: undefined reference to `ber_sockbuf_add_io@OPENLDAP_2.4_2' libcurl-gnutls.so.4.4.0: undefined reference to `ldap_unbind_ext@OPENLDAP_2.4_2' libcurl-gnutls.so.4.4.0: undefined reference to `ldap_get_attribute_ber@OPENLDAP_2.4_2' libcurl-gnutls.so.4.4.0: undefined reference to `RTMP_SetBufferMS' libcurl-gnutls.so.4.4.0: undefined reference to `ldap_parse_result@OPENLDAP_2.4_2' libcurl-gnutls.so.4.4.0: undefined reference to `RTMP_Init' libcurl-gnutls.so.4.4.0: undefined reference to `RTMP_Connect1' libcurl-gnutls.so.4.4.0: undefined reference to `ldap_set_option@OPENLDAP_2.4_2' libcurl-gnutls.so.4.4.0: undefined reference to `RTMP_SetupURL' libcurl-gnutls.so.4.4.0: undefined reference to `ldap_abandon_ext@OPENLDAP_2.4_2' libcurl-gnutls.so.4.4.0: undefined reference to `ldap_msgfree@OPENLDAP_2.4_2' libcurl-gnutls.so.4.4.0: undefined reference to `ldap_result@OPENLDAP_2.4_2' libglib-2.0.so.0: undefined reference to `pcre_get_stringtable_entries' libglib-2.0.so.0: undefined reference to `pcre_get_stringnumber' libcurl-gnutls.so.4.4.0: undefined reference to `ldap_search_ext@OPENLDAP_2.4_2' //lib64/libresolv.so.2: undefined reference to `__res_maybe_init@GLIBC_PRIVATE' libcurl-gnutls.so.4.4.0: undefined reference to `ldap_get_option@OPENLDAP_2.4_2' libcurl-gnutls.so.4.4.0: undefined reference to `ber_memfree@OPENLDAP_2.4_2' libglib-2.0.so.0: undefined reference to `pcre_config' libglib-2.0.so.0: undefined reference to `pcre_compile2' libcurl-gnutls.so.4.4.0: undefined reference to `RTMP_Write' libgnutls.so.30: undefined reference to `nettle_secp_192r1@HOGWEED_4' libcurl-gnutls.so.4.4.0: undefined reference to `ldap_memfree@OPENLDAP_2.4_2' libglib-2.0.so.0: undefined reference to `pcre_free' libcurl-gnutls.so.4.4.0: undefined reference to `ldap_pvt_url_scheme2proto@OPENLDAP_2.4_2' libcurl-gnutls.so.4.4.0: undefined reference to `RTMP_ConnectStream' libselinux.so.1: undefined reference to `pcre_free_study' libcurl-gnutls.so.4.4.0: undefined reference to `ldap_next_message@OPENLDAP_2.4_2' libcurl-gnutls.so.4.4.0: undefined reference to `RTMP_Close' libcurl-gnutls.so.4.4.0: undefined reference to `ber_free@OPENLDAP_2.4_2' libglib-2.0.so.0: undefined reference to `pcre_exec' libgnutls.so.30: undefined reference to `nettle_secp_224r1@HOGWEED_4' libcurl-gnutls.so.4.4.0: undefined reference to `ldap_err2string@OPENLDAP_2.4_2' libcurl-gnutls.so.4.4.0: undefined reference to `ldap_init_fd@OPENLDAP_2.4_2' libselinux.so.1: undefined reference to `pcre_compile' libcurl-gnutls.so.4.4.0: undefined reference to `ldap_msgtype@OPENLDAP_2.4_2' libglib-2.0.so.0: undefined reference to `pcre_study' libcurl-gnutls.so.4.4.0: undefined reference to `RTMP_Free' libcurl-gnutls.so.4.4.0: undefined reference to `ldap_free_urldesc@OPENLDAP_2.4_2' libcurl-gnutls.so.4.4.0: undefined reference to `ldap_url_parse@OPENLDAP_2.4_2' libcurl-gnutls.so.4.4.0: undefined reference to `RTMP_Read' libcurl-gnutls.so.4.4.0: undefined reference to `RTMP_Alloc' libglib-2.0.so.0: undefined reference to `pcre_dfa_exec' libselinux.so.1: undefined reference to `pcre_version' libcurl-gnutls.so.4.4.0: undefined reference to `ldap_first_message@OPENLDAP_2.4_2'
The testcase needs -rpath=. to search . first for dependent libraries not mentioned on the command line, and these libraries are missing: libblkid.so.1 libgpg-error.so.0 libkrb5.so.3 libk5crypto.so.3 libcom_err.so.2 libkrb5support.so.0 libsasl2.so.2 libgssapi.so.3 libkeyutils.so.1 libheimntlm.so.0 libkrb5.so.26 libasn1.so.8 libhcrypto.so.4 libroken.so.18 libwind.so.0 libheimbase.so.1 libhx509.so.5 libsqlite3.so.0 libcrypt.so.1 If I use my Ubuntu 16.04 system libs for the above, then I see ./libgssapi_krb5.so.2: undefined reference to `k5_os_mutex_unlock@krb5support_0_MIT' ./libgssapi_krb5.so.2: undefined reference to `k5_os_mutex_init@krb5support_0_MIT' ./libgssapi_krb5.so.2: undefined reference to `k5_os_mutex_lock@krb5support_0_MIT' ./libgssapi_krb5.so.2: undefined reference to `k5_once@krb5support_0_MIT' ./libgssapi_krb5.so.2: undefined reference to `k5_os_mutex_destroy@krb5support_0_MIT'
sorry, I updated the test tarball. Alan, this is artful (both release and proposed pockets enabled).
OK, so I can work around the missing symbols with --allow-shlib-undefined, and reproduce the problem. The changed behaviour is due to running elf_gc_sweep_symbol after setting version refs. ie. the fix for pr20828, git commit 902e9fc76a. With 2.29, __explicit_bzero_chk@@GLIBC_2.25 triggers the GLIBC_2.25 version ref. With 2.28 that symbol has dynindx set to -1 by elf_gc_sweep_symbol before version refs are calculated.
I think this can be fixed by running elf_gc_sweep_symbol before we calculate version refs, but leaving it after version defs.
The master branch has been updated by Alan Modra <amodra@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=3d13f3e9bda5aada68915f5d958f731ae79ed41d commit 3d13f3e9bda5aada68915f5d958f731ae79ed41d Author: Alan Modra <amodra@gmail.com> Date: Tue Sep 19 11:59:30 2017 +0930 PR22150, ld keeps a version reference for gc'd symbols elf_gc_sweep_symbol should run after verdefs are calculated, since the verdef code creates symbols for the versions. However, elf_gc_sweep_symbol needs to run before verrefs so as to not emit useless verrefs for symbols that are gc'd. I've also removed a _bfd_elf_link_renumber_dynsyms calls added by Maciej after I fussed about it when reviewing. On further examination the call appears to be unnecessary. Looking at renumber_dynsyms also made me realize that the test to exclude .gnu.version has been wrong since 2016-04-26 (git commit d5486c4372), so fix that too. PR 22150 * elflink.c (bfd_elf_size_dynamic_sections): Garbage collect symbols before calculating verrefs. Don't renumber dynsyms after gc. Exclude .gnu.version when zero or one dynsym. Localize some vars and reindent.
The binutils-2_29-branch branch has been updated by Alan Modra <amodra@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c01ee74d3ad56a25272dfd5607ce4a807223e7e5 commit c01ee74d3ad56a25272dfd5607ce4a807223e7e5 Author: Alan Modra <amodra@gmail.com> Date: Tue Sep 19 11:59:30 2017 +0930 PR22150, ld keeps a version reference for gc'd symbols elf_gc_sweep_symbol should run after verdefs are calculated, since the verdef code creates symbols for the versions. However, elf_gc_sweep_symbol needs to run before verrefs so as to not emit useless verrefs for symbols that are gc'd. I've also removed a _bfd_elf_link_renumber_dynsyms calls added by Maciej after I fussed about it when reviewing. On further examination the call appears to be unnecessary. Looking at renumber_dynsyms also made me realize that the test to exclude .gnu.version has been wrong since 2016-04-26 (git commit d5486c4372), so fix that too. PR 22150 * elflink.c (bfd_elf_size_dynamic_sections): Garbage collect symbols before calculating verrefs. Don't renumber dynsyms after gc. Exclude .gnu.version when zero or one dynsym. Localize some vars and reindent. (cherry picked from commit 3d13f3e9bda5aada68915f5d958f731ae79ed41d)
Should be fixed now
The master branch has been updated by H.J. Lu <hjl@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=be2b629f6427812a24f38802ba1c472a2cbfab7d commit be2b629f6427812a24f38802ba1c472a2cbfab7d Author: H.J. Lu <hjl.tools@gmail.com> Date: Fri Sep 22 06:58:48 2017 -0700 Add a test for PR ld/22150 PR ld/22150 * testsuite/ld-elf/pr22150.vd: New file. * testsuite/ld-elf/pr22150.ver: Likewise. * testsuite/ld-elf/pr22150a.s: Likewise. * testsuite/ld-elf/pr22150b.s: Likewise. * testsuite/ld-elf/shared.exp: Run PR ld/22150 tests.