Bug#807830: arm: -fstack-protector-strong adds dependency on ld-linux-aarch64.so.1 on arm64

[uwe@kleine-koenig.org (Uwe Kleine-Koenig)]

Package: gcc-5
Version: 5.3.1-3
Severity: normal

Hello,

I'm not sure if gcc is the right package to report this problem for, but not
knowing it better I picked gcc, please reassign if needed.

In the buildlog of memtool on arm64[1] I found a message:

        dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/memtool/usr/sbin/memtool was not linked against ld-linux-aarch64.so.1 (it uses none of the library's symbols)

This is surprising because ld-linux-aarch64.so.1 isn't mentioned explicitly and
it should only be pulled in when needed:

        (sid_arm64-dchroot)ukleinek@asachi:~$ cat /usr/lib/aarch64-linux-gnu/libc.so
        /* GNU ld script
           Use the shared library, but some functions are only in
           the static library, so try that secondarily.  */
        OUTPUT_FORMAT(elf64-littleaarch64)
        GROUP ( /lib/aarch64-linux-gnu/libc.so.6 /usr/lib/aarch64-linux-gnu/libc_nonshared.a  AS_NEEDED ( /lib/aarch64-linux-gnu/ld-linux-aarch64.so.1 ) )

The same problem (of course with a different lib name) is logged in the
armhf and armel build logs.

This is reproducible on asachi.debian.org in a sid chroot and only if
-fstack-protector-strong is passed:

        (sid_arm64-dchroot)ukleinek@asachi:~$ cat test.c
        #include <stdio.h>
        #include <stdlib.h>

        int main(int argc, char **argv)
        {
                char *end;
                unsigned long long val = strtoull(argv[1], &end, 0);
                printf("Hello World! %llu\n", val);
                return EXIT_SUCCESS;
        }
        (sid_arm64-dchroot)ukleinek@asachi:~$ gcc -fstack-protector-strong -o test test.c; objdump -p test | grep NEEDED
          NEEDED               libc.so.6
          NEEDED               ld-linux-aarch64.so.1
        (sid_arm64-dchroot)ukleinek@asachi:~$ gcc -o test test.c; objdump -p test | grep NEEDED
          NEEDED               libc.so.6

I would expect that adding -fstack-protector-strong shouldn't
introduce a useless dependency to ld-linux-aarch64.so.1. So either this
dependency is unused (in which case there is something wrong in the
linker) or dpkg-shlibdeps' diagnose is wrong (then dpkg-shlibdeps should
be fixed and this bug reassigned accordingly).

Best regards
Uwe

[1] https://buildd.debian.org/status/fetch.php?pkg=memtool&arch=arm64&ver=2015.12.2-1&stamp=1449831548

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: arm64 (aarch64)

Kernel: Linux 3.16.0-4-arm64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages gcc-5 depends on:
ii  binutils      2.25.90.20151125-2
ii  cpp-5         5.3.1-3
ii  gcc-5-base    5.3.1-3
ii  libc6         2.21-3
ii  libcc1-0      5.3.1-3
ii  libgcc-5-dev  5.3.1-3
ii  libgcc1       1:5.3.1-3
ii  libgmp10      2:6.1.0+dfsg-2
ii  libisl15      0.15-3
ii  libmpc3       1.0.3-1
ii  libmpfr4      3.1.3-1
ii  libstdc++6    5.3.1-3
ii  zlib1g        1:1.2.8.dfsg-2+b1

Versions of packages gcc-5 recommends:
ii  libc6-dev  2.21-3

Versions of packages gcc-5 suggests:
pn  gcc-5-doc        <none>
pn  gcc-5-locales    <none>
pn  libasan2-dbg     <none>
pn  libatomic1-dbg   <none>
pn  libcilkrts5-dbg  <none>
pn  libgcc1-dbg      <none>
pn  libgomp1-dbg     <none>
pn  libitm1-dbg      <none>
pn  liblsan0-dbg     <none>
pn  libmpx0-dbg      <none>
pn  libquadmath-dbg  <none>
pn  libtsan0-dbg     <none>
pn  libubsan0-dbg    <none>

-- no debconf information