in memory sanitizer builds -stdlib=libc++ is linking against /usr/local/lib/libc++.a not /usr/lib/libc++.a

[caolanm]

/usr/local/bin/compile has...

if [[ $SANITIZER_FLAGS = sanitize=memory ]]
then
cp -R /usr/msan/lib/* /usr/lib/

echo 'Building without MSan instrumented libraries.'
fi

so for memory sanitizer builds the /usr/msan/lib/libc++.a is copied to /usr/lib but clang++ -stdlib=libc++ ends up linking against the one in /usr/local/lib

root@5d4ceecbe072:~# strace -f clang++ -stdlib=libc++ ./demo.cxx 2>&1 | grep libc++.a
[pid 717148] stat("/usr/lib/gcc/x86_64-linux-gnu/9/libc++.a", 0x7ffcc35a1a60) = -1 ENOENT (No such file or directory)
[pid 717148] openat(AT_FDCWD, "/usr/lib/gcc/x86_64-linux-gnu/9/libc++.a", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 717148] stat("/usr/lib/gcc/x86_64-linux-gnu/9/../../../../lib64/libc++.a", 0x7ffcc35a1a60) = -1 ENOENT (No such file or directory)
[pid 717148] openat(AT_FDCWD, "/usr/lib/gcc/x86_64-linux-gnu/9/../../../../lib64/libc++.a", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 717148] stat("/lib/x86_64-linux-gnu/libc++.a", 0x7ffcc35a1a60) = -1 ENOENT (No such file or directory)
[pid 717148] openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc++.a", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 717148] stat("/lib/../lib64/libc++.a", 0x7ffcc35a1a60) = -1 ENOENT (No such file or directory)
[pid 717148] openat(AT_FDCWD, "/lib/../lib64/libc++.a", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 717148] stat("/usr/lib/x86_64-linux-gnu/libc++.a", 0x7ffcc35a1a60) = -1 ENOENT (No such file or directory)
[pid 717148] openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libc++.a", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 717148] stat("/usr/lib/../lib64/libc++.a", 0x7ffcc35a1a60) = -1 ENOENT (No such file or directory)
[pid 717148] openat(AT_FDCWD, "/usr/lib/../lib64/libc++.a", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 717148] stat("/usr/local/bin/../lib/libc++.a", {st_mode=S_IFREG|0644, st_size=2622420, ...}) = 0
[pid 717148] openat(AT_FDCWD, "/usr/local/bin/../lib/libc++.a", O_RDONLY) = 8
[pid 717148] write(2, "/usr/local/bin/../lib/libc++.a(c"..., 59/usr/local/bin/../lib/libc++.a(cxa_exception_storage.cpp.o)) = 59
[pid 717148] write(2, "/usr/local/bin/../lib/libc++.a(c"..., 59/usr/local/bin/../lib/libc++.a(cxa_exception_storage.cpp.o)) = 59
[pid 717148] write(2, "/usr/local/bin/../lib/libc++.a(c"..., 59/usr/local/bin/../lib/libc++.a(cxa_exception_storage.cpp.o)) = 59
[pid 717148] write(2, "/usr/local/bin/../lib/libc++.a(c"..., 59/usr/local/bin/../lib/libc++.a(cxa_exception_storage.cpp.o)) = 59

I suspect this is happening since a2be91d seeing as libreoffice, libigl and librawspeed started failing with similar errors in their msan builds around the 10th Sep

[jonathanmetzman]

I'll probably take a look at this on Friday.

[rouault]

I've had a somewhat related issue, on a x86 asan build, where the GDAL ./configure checks fail to work properly when testing the presence of some features because the presence of the 64-bit /usr/local/lib/libc++.a caused the following warning:
/usr/bin/ld: skipping incompatible /usr/local/bin/../lib/libc++.a when searching for -lc++

[jonathanmetzman]

I've had a somewhat related issue, on a x86 asan build, where the GDAL ./configure checks fail to work properly when testing the presence of some features because the presence of the 64-bit /usr/local/lib/libc++.a caused the following warning:
/usr/bin/ld: skipping incompatible /usr/local/bin/../lib/libc++.a when searching for -lc++

I'm going to fix the issue for both MSAN and i386. But it seems like gdal is having a different libc++ issue in x86_64 ASAN builds that is unrelated right? https://oss-fuzz-build-logs.storage.googleapis.com/log-678363f4-c40c-4c55-9ce5-db855b59a697.txt

[rouault]

But it seems like gdal is having a different libc++ issue in x86_64 ASAN builds that is unrelated right?

hum, if it has just appears, this is likely a side effect of my commit OSGeo/gdal@b038915 to workaround the i386 issue. This workaround seemed to work fine for libfuzzer enging, but perhaps it breaks with AFL indeed