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

Thanks for reporting this. I haven't recreated the issue yet; but for 
the purposes of this message I'll assume that this is an issue that 
isn't caused by quirks in your environment.

Let me check my understanding, but I think I understand the issue.

Conventionally `-fsanitize=address' "just works" with GCC because 
`libgcc_s.so', `libasan.so', and similar libraries can be automatically 
added using "flag specs".
Because `libtool' uses `-nostdlib' and tries to explicitly handle any 
"flag specs" ( such as `-fsanitize=address' ) that are encountered, it 
needs to stay updated in lock-step with changes to GCC's specs, or 
`libtool' needs to be able to parse and replicate the behavior of 
`{gcc,g++} -dumpspec' definitions as if `-nostdlib' had not been indicated.

In short `libtool' fails to replicate the spec for `-fsanitize=address', 
because of conflicts with the added `-nostdlib' flag.

Two possible solutions may be:
1. If `libtool' is going to silently add `-nostlib', it needs to be sure 
it accounts for flag specs such as `-fsanitize=address'.

2. `libtool' should trust the underlying compiler/link-editor to select 
the correct standard libraries, and only use `-nostdlib' when the user 
explicitly requests it.


If my understanding is correct, and the potential solutions would work; 
I personally lean towards (2), since I don't immediately see a good 
rationale for why `libtool' should disable the compiler/link-editor's 
preferred libraries.

Just for clarity, I do understand the purpose of `-nostlib' and I know 
that it's incredibly useful; but using it silently by default foists a 
huge responsibility onto `libtool' to avoid common use cases like the 
one you've got here.


On 4/28/22 05:35, Jan Engelhardt wrote:
>
> 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)
>