libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alex Ameen
Subject: Re: Use of -fsanitize=address still leads to unresolved symbols on gcc
Date: Sat, 30 Apr 2022 12:58:13 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0

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)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]