Bug#909267: library-not-linked-against-libc: downgrade from error
Chris Lamb <lamby@debian.org> writes:
> Dear Simon et al.,
>> Was the goal of this tag to tell the difference between libraries that
>> are linked to their dependencies, and libraries that aren't, like the
>> difference between these?
>>
>> $ gcc -shared -Wl,-soname,libbad.so.0 -olibbad.so.0 libhello.c `pkg-
>> config --cflags glib-2.0`
>> $ gcc -shared -Wl,-soname,libgood.so.0 -olibgood.so.0 libhello.c `pkg-
>> config --cflags --libs glib-2.0`
> I'm afraid I simply don't know and alas am simply not well-versed
> enough in shared library foo to make any kind of judgement or even
> comment; just playing the "triager" role. Can another lintian developer
> chime in here?
My recollection is that Simon is correct and we added this tag to try to
find shared libraries that weren't linked to any of their dependencies.
At the time, we made the assumption that nearly every shared library would
use *something* from libc and thus have to be linked to it.
> Random thought; if this just affects "gnome packages", can we just skip
> those? (If so, how?)
Maybe exclude shared libraries linked with glib (and whatever the Qt
equivalent is)? I think it's still true that nearly every library is
going to require *some* implementation of basic string handling, memory
management, etc.; it's just that for a lot of GNOME stuff all of that is
done by glib wrappers instead of directly by libc, and presumably
something similar for Qt.
It's also possible that subsequent tooling changes have made the original
problem less likely and we don't need this tag at all. The tag is
detecting something that's not technically wrong -- there's no reason why
a shared library needs to be linked to anything at all. It's just
assuming the NEEDED metadata is erroneously missing even though the
library has undefined symbols, as opposed to a shared library that really
doesn't need other libraries.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: