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)
