On 29.07.23 06:30, Helmut Grohne wrote:
Package: lib32lsan0,lib64lsan0,libx32lsan0 Version: 13.1.0-9 Severity: importantHi Matthias, I am a bit confused about lib*lsan0. These are support libraries for the leak sanitizer, but the multilib ones are empty (and the package description even says so). However, these packages don't seem to work. $ printf "int main(){}" | gcc -fsanitize=leak -xc - $ printf "int main(){}" | gcc -fsanitize=leak -xc - -m32 /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/13/liblsan.so when searching for -llsan /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/13/liblsan.a when searching for -llsan /usr/bin/ld: cannot find -llsan: No such file or directory /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/13/liblsan.so when searching for -llsan collect2: error: ld returned 1 exit status $ This is in unstable with gcc-multilib, libgcc-13-dev and lib32lsan0 installed. Another hint that something is wrong is a comparison with the address sanitizer. lib32asan8 is non-empty and -fsanitize=address tends to work with a multilib. I conclude that this is not working as intended. At this point, the best course of action from my point of view is removing the multilib lsan packages as they evidently do not work at all. Do you agree? Why did I look into this? The multilib lsan packages happen to ship empty directories /usr/lib{32,64,x32}. These directories are technically susceptible to loss due to the /usr-merge. Quite probably, these directories can be removed from the binary packages without loss of functionality (which?), but that effort is wasted if we end up removing these packages altogether.
see src/libsanitizer/configure.tgt, it's unsupported, the empty packages don't hurt. Feel free to send a patch not to build these packages, tested please for amd64 and i386 builds, plus cross builds targeting these architectures.
thanks, Matthias
