Bug#1042482: multilib lsan packages: dysfunctional?
Control: clone -1 -2 Control: retitle -2 gcc-13: missing debhelper dependency for cross toolchain builds Control: tags -2 = Control: severity -2 normal Hi Matthias, On Sun, Jul 30, 2023 at 09:40:35PM +0200, Helmut Grohne wrote: > On Sun, Jul 30, 2023 at 07:10:09AM +0200, Matthias Klose wrote: > > 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. > > Thank you for pointing there. A key insight there is that lsan does not > work for 32bit architectures at all. Therefore, we can entirely remove > the 32bit lsan multilib packages. Surprisingly, the lib64lsan0 package > is already commented, so we don't have to consider that. I've > implemented the requested change and performed a local native build on > amd64. I've also performed the requested i386 build (though lintian > OOMed there). I've not performed cross builds since we know that those > are broken. You privately clarified that you meant cross toolchain builds (build = host != target) rather than cross builds (build != host = target). I also attempted building a cross toolchain for i386 on amd64. Such builds fail, because Build-Depends lack debhelper and therefore dh_clean fails. DEBHELPER_BUILD_DEP is never set when DEB_CROSS equals yes and therefore no debhelper dependency is emitted. This failure is unrelated to my patch. Therefore, my patch does not regress this aspect. > Do you need any artifacts? .debs? build logs? I think the patch is > pretty straight forward. Is there anything else you need? Helmut
Bug#1042482: multilib lsan packages: dysfunctional?
Control: tags -1 + patch
Hi Matthias,
On Sun, Jul 30, 2023 at 07:10:09AM +0200, Matthias Klose wrote:
> 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.
Thank you for pointing there. A key insight there is that lsan does not
work for 32bit architectures at all. Therefore, we can entirely remove
the 32bit lsan multilib packages. Surprisingly, the lib64lsan0 package
is already commented, so we don't have to consider that. I've
implemented the requested change and performed a local native build on
amd64. I've also performed the requested i386 build (though lintian
OOMed there). I've not performed cross builds since we know that those
are broken.
Do you need any artifacts? .debs? build logs? I think the patch is
pretty straight forward.
Helmut
--- gcc-13-13.1.0/debian/changelog
+++ gcc-13-13.1.0/debian/changelog
@@ -1,3 +1,10 @@
+gcc-13 (13.1.0-9.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Delete 32bit liblsan packages. (Closes: #1042482)
+
+ -- Helmut Grohne Sun, 30 Jul 2023 10:49:50 +0200
+
gcc-13 (13.1.0-9) unstable; urgency=medium
* Update to git 20230720 from the gcc-13 branch (13.2 release candidate).
--- gcc-13-13.1.0/debian/control
+++ gcc-13-13.1.0/debian/control
@@ -596,17 +596,6 @@
LeakSanitizer (Lsan) is a memory leak detector which is integrated
into AddressSanitizer.
-Package: lib32lsan0
-X-DH-Build-For-Type: target
-Section: libs
-Architecture: amd64 ppc64 kfreebsd-amd64 s390x sparc64 x32 mipsn32 mipsn32el
mips64 mips64el mipsn32r6 mipsn32r6el mips64r6 mips64r6el
-Priority: optional
-Depends: gcc-13-base (= ${gcc:Version}), ${dep:libcbiarch}, ${shlibs:Depends},
${misc:Depends}
-Conflicts: ${confl:lib32}
-Description: LeakSanitizer -- a memory leak detector (32bit)
- LeakSanitizer (Lsan) is a memory leak detector which is integrated
- into AddressSanitizer (empty package).
-
#Package: lib64lsan`'LSAN_SO`'LS
#Section: ifdef(`TARGET',`devel',`libs')
#Architecture: ifdef(`TARGET',`CROSS_ARCH',`biarch64_archs')
@@ -617,26 +606,6 @@
# LeakSanitizer (Lsan) is a memory leak detector which is integrated
# into AddressSanitizer.
-#Package: libn32lsan`'LSAN_SO`'LS
-#Section: ifdef(`TARGET',`devel',`libs')
-#Architecture: ifdef(`TARGET',`CROSS_ARCH',`biarchn32_archs')
-#Priority: optional
-#Depends: BASELDEP, ${dep:libcbiarch}, ${shlibs:Depends}, ${misc:Depends}
-#BUILT_USING`'dnl
-#Description: LeakSanitizer -- a memory leak detector (n32)
-# LeakSanitizer (Lsan) is a memory leak detector which is integrated
-# into AddressSanitizer.
-
-Package: libx32lsan0
-X-DH-Build-For-Type: target
-Section: libs
-Architecture: amd64 i386
-Priority: optional
-Depends: gcc-13-base (= ${gcc:Version}), ${dep:libcbiarch}, ${shlibs:Depends},
${misc:Depends}
-Description: LeakSanitizer -- a memory leak detector (x32)
- LeakSanitizer (Lsan) is a memory leak detector which is integrated
- into AddressSanitizer (empty package).
-
Package: libtsan2
X-DH-Build-For-Type: target
Section: libs
--- gcc-13-13.1.0/debian/control.m4
+++ gcc-13-13.1.0/debian/control.m4
@@ -2094,33 +2094,6 @@
into AddressSanitizer.
')`'dnl libdbg
-ifenabled(`lib32lsan',`
-Package: lib32lsan`'LSAN_SO`'LS
-TARGET_PACKAGE`'dnl
-Section: ifdef(`TARGET',`devel',`libs')
-Architecture: ifdef(`TARGET',`CROSS_ARCH',`biarch32_archs')
-Priority: optional
-Depends: BASELDEP, ${dep:libcbiarch}, ${shlibs:Depends}, ${misc:Depends}
-Conflicts: ${confl:lib32}
-BUILT_USING`'dnl
-Description: LeakSanitizer -- a memory leak detector (32bit)
- LeakSanitizer (Lsan) is a memory leak detector which is integrated
- into AddressSanitizer (empty package).
-
-ifenabled(`libdbg',`
-Package: lib32lsan`'LSAN_SO-dbg`'LS
-TARGET_PACKAGE`'dnl
-Architecture: ifdef(`TARGET',`CROSS_ARCH',`biarch32_archs')
-Section: debug
-Priority: optional
-Depends: BASELDEP, libdep(lsan`'LSAN_SO,32,=), ${misc:Depends}
-BUILT_USING`'dnl
-Description: LeakSanitizer -- a memory leak detector (32 bit debug symbols)
- LeakSanitizer (Lsan) is a memory leak detector which is integrated
- into AddressSanitizer (empty package).
-')`'dnl libdbg
-')`'dnl lib32lsan
-
ifenabled(`lib64lsan',`
#Package: lib64lsan`'LSAN_SO`'LS
#Section: ifdef(`TARGET',`devel',`libs')
@@ -2144,110 +2117,6 @@
# into AddressSanitizer.
')`'dnl libdbg
')`'dnl lib64lsan
-
-ifenabled(`libn32lsan',`
-#Package: libn32lsan`'LSAN_SO`'LS
-#Section: ifdef(`TARGET',`devel',`libs')
-#Architecture: ifdef(`TARGET',`CROSS_ARCH',`biarchn32_archs')
-#Priority: optional
-#Depends: BASELDEP, ${dep:libcbiarch}, ${shlibs:Depends}, ${misc:Depends}
-#BUILT_USING`'dnl
-#Description: LeakSanitizer -- a memory leak detector (n32)
-# LeakSanitizer (Lsan) is a memory leak detector which is integrated
-# into AddressSanitizer.
-
-ifenabled(`libdbg',`
-#Package: libn32lsan`'LSAN_SO-dbg`'LS
-#Architecture:
Bug#1042482: multilib lsan packages: dysfunctional?
On 29.07.23 06:30, Helmut Grohne wrote:
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.
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
Bug#1042482: multilib lsan packages: dysfunctional?
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
