On 27/01/2025 23:14, Russ Allbery wrote:
Ahmad Khalifa <ah...@khalifa.ws> writes:
Having said that, lintian is slow enough as a single thread, I'd vote for
downgrading the tag to Pedantic, but not deleting it.
So, I guess I'll say this more explicitly: I am opposed to downgrading the
tag to pedantic. If the tag is useful, we should fix it; if it's not
useful, we should delete it.
It's not a pedantic issue with the package. If the error is real, it's
serious, but Lintian's check for the error has a high false positive rate.
That's not what pedantic is for. Pedantic is intended for tags where
Lintian has correctly understood the thing that it is complaining about,
but people do not always agree that thing is worth fixing.
If you really want to keep the tag despite a lot of false positives, the
way to do that would be to make it experimental, but I think experimental
tags are often a dumping ground for things that will never be fixed and it
might be better to just delete it.
With your definition, I agree, it's not something to be pedantic about,
it's not a real error.
Here is a quick check I did on random packages from udd [1]:
Picking abseil (300+ overridden), clanlib (9 error) and chicken (300+ error)
# download the relevant debs (sorry formatting)
wget
https://ftp.debian.org/debian/pool/main/a/abseil/libabsl20230802_20230802.1-4_{amd64,arm64,armel,armhf,i386,mips64el,mipsel,ppc64el,s390x,riscv64}.deb
wget
https://ftp.debian.org/debian/pool/main/c/clanlib/libclanapp-1.0t64_1.0~svn3827-11.2+b1_{amd64,arm64,armel,armhf,i386,mips64el,mipsel,ppc64el,s390x,riscv64}.deb
wget
https://ftp.debian.org/debian/pool/main/c/chicken/chicken-bin_5.3.0-2_{amd64,arm64,armel,armhf,i386,mips64el,mipsel,ppc64el,s390x,riscv64}.deb
# extract
for f in *.deb; do dpkg --extract "$f" ROOT; done
# check for GLIBC symbol without NEEDED libc, libm or loaders
for f in ROOT/usr/lib/*-linux-gnu/*.so.* ROOT/var/lib/chicken/11/*.so*; do
(objdump -T "$f" | grep " (GLIBC_[0-9]" > /dev/null) &&
( (objdump -p "$f" | grep -E 'NEEDED *libc.so|NEEDED *libm.so|NEEDED
*ld-linux.*.so|NEEDED *ld64.so' > /dev/null) || echo "bad so: $f");
done
Outputs nothing.
Meaning for all libc dynamic symbols, the linker will load one of the
libc libraries.
But reading that, I don't see how the linker could declare a dynamic
GLIBC_ symbol without the related library reference.
In fact, it should choke with "undefined reference" long before
outputting a .so file. Even when compiling with -nolibc. But there is
always a special case somewhere :)
And if the linker wrote broken dynamic sections, I doubt lintian could
find out from just inspecting the .so.
Perhaps the tag really is not relevant anymore or someone has a better test.
1.
https://udd.debian.org/lintian-tag/library-not-linked-against-libc?affected=yes
--
Regards,
Ahmad
