[Top][All Lists]

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

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

From: Jan Engelhardt
Subject: Use of -fsanitize=address still leads to unresolved symbols on gcc
Date: Thu, 28 Apr 2022 12:35:01 +0200 (CEST)
User-agent: Alpine 2.25 (LSU 592 2021-09-18)

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 foo.lo
libtool: link: g++  -fPIC -DPIC -shared -nostdlib 
/usr/lib64/gcc/x86_64-suse-linux/11/crtbeginS.o  .libs/foo.o   
-L/usr/lib64/gcc/x86_64-suse-linux/11/../../../../lib64 -L/lib/../lib64 
-L/usr/lib64/gcc/x86_64-suse-linux/11/../../.. -lstdc++ -lm -lc -lgcc_s 
-fsanitize=address   -Wl,-soname -Wl, -o .libs/

$ ldd -r .libs/ (0x00007ffeb1dc1000) => /lib64/ (0x00007f6b0719d000) => /lib64/ (0x00007f6b070b5000) => /lib64/ (0x00007f6b06e86000) => /lib64/ (0x00007f6b06e63000)
        /lib64/ (0x00007f6b073e5000)
undefined symbol: __asan_init   (.libs/
undefined symbol: __asan_version_mismatch_check_v8      (.libs/

reply via email to

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