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.
