Use of -fsanitize=address still leads to unresolved symbols on gcc

libtool (2.4.7, and earlier versions) pass -nostdlib to the linker
command. This would seem to cause ASAN/UBSAN libraries not to be
linked, and a situation of unresolved symbols arises.

Commit a5c6466528c060cc4660ad0319c00740db0e42ba certainly feels right
(hence the "earlier versions"), but apparently didn't do anything
with regards to gcc.

gcc-11.2.1/binutils 2.38.20220411-4 is in use.


$ echo 'int blah() { return 42; }' >foo.cpp
$ ./libtool --tag=CXX --mode=compile g++ -fsanitize=address -c foo.cpp
libtool: compile:  g++ -fsanitize=address -c foo.cpp  -fPIC -DPIC -o .libs/foo.o

$ ./libtool --tag=CXX --mode=link g++ -fsanitize=address -rpath /usr/lib64 -o libfoo.la foo.lo
libtool: link: g++  -fPIC -DPIC -shared -nostdlib /usr/lib64/gcc/x86_64-suse-linux/11/../../../../lib64/crti.o /usr/lib64/gcc/x86_64-suse-linux/11/crtbeginS.o  .libs/foo.o   -L/usr/lib64/gcc/x86_64-suse-linux/11 -L/usr/lib64/gcc/x86_64-suse-linux/11/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib64/gcc/x86_64-suse-linux/11/../../../../x86_64-suse-linux/lib -L/usr/lib64/gcc/x86_64-suse-linux/11/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib64/gcc/x86_64-suse-linux/11/crtendS.o /usr/lib64/gcc/x86_64-suse-linux/11/../../../../lib64/crtn.o  -fsanitize=address   -Wl,-soname -Wl,libfoo.so.0 -o .libs/libfoo.so.0.0.0

$ ldd -r .libs/libfoo.so.0
        linux-vdso.so.1 (0x00007ffeb1dc1000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f6b0719d000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f6b070b5000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f6b06e86000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f6b06e63000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f6b073e5000)
undefined symbol: __asan_init   (.libs/libfoo.so.0)
undefined symbol: __asan_version_mismatch_check_v8      (.libs/libfoo.so.0)