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

[Edmund Grimley Evans <edmund.grimley.evans@gmail.com>]

I'd say this is a bug in dpkg-shlibdeps in dpkg-dev.

Referring to the example above, on arm64 "test" does depend on
ld-linux-aarch64.so.1 because, although "__stack_chk_guard" is defined
in "test", there's also a relocation referring to the one in
/lib/ld-linux-aarch64.so.1:

$ nm test | grep stack_chk_guard
0000000000410a38 B __stack_chk_guard@@GLIBC_2.17

$ objdump -R test | grep stack_chk_guard
0000000000410a38 R_AARCH64_COPY    __stack_chk_guard@@GLIBC_2.17

$ nm -D /lib/ld-linux-aarch64.so.1 | grep stack_chk_guard
000000000002bdd8 D __stack_chk_guard

So dpkg-shlibdeps should be a bit cleverer, I would guess.

As I understand it, the difference between amd64 and arm64 comes from
how the stack-protector stuff is implemented differently on the two
architectures: on amd64 thread-local storage is used instead of a
global variable.

The kind of linking that's happening on arm64 can be demonstrated on
amd64 like this:

echo 'int foo = 7;' > lib.c
gcc -fPIC -c lib.c
gcc -shared lib.o -o liblib.so
nm -D liblib.so  | grep foo

echo 'extern int foo; int main() { return foo; }' > prog.c
gcc -c prog.c
gcc prog.o -L. -llib -o prog
nm prog | grep foo

$ ./prog
./prog: error while loading shared libraries: liblib.so: cannot open shared object file: No such file or directory

$ LD_LIBRARY_PATH=. ./prog
$ echo $?
7

The value 7 comes from the shared library.

Please reassign this bug if you agree with my reasoning.