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

Bug#1043248: marked as done (gcc-13: missing debhelper dependency for cross toolchain builds)

Your message dated Fri, 24 Nov 2023 12:19:23 +0100
with message-id <[🔎] 5f409e5c-e09d-40d8-a5d1-0d35d8d21960@debian.org>
and subject line fixed in gcc-13
has caused the Debian Bug report #1043248,
regarding gcc-13: missing debhelper dependency for cross toolchain builds
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1043248: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043248
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: lib32lsan0,lib64lsan0,libx32lsan0
Version: 13.1.0-9
Severity: important

Hi 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.

Helmut

--- End Message ---
--- Begin Message --- 
fixed in gcc-13

--- End Message ---
Reply to: