Bugzilla Bug 98715

I don't know what is the Gentoo-soname policy, but one can read here Debians
(http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#sonames)
and after a little bit of exploration, I found a couple of packages with broken
sonames. I'll file bugs for all of them with the corresponding patches. The
information in the SONAME-field could be used for automatic
reverse-dependancies retrieval and so on, without the use of ld-linux.so
interpreter (which BTW has serious security implications - possibility for code
execution -
http://www.tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN115). 
If the devs, think that this is not a priority or didn't need this information,
please tell me and I'll stop filing the bugs.

I've hacked the following find for finding missing soname-tags:

$ find /usr/lib -name \*.so -type f -exec sh -c 'echo {}:$(objdump -p {}
2>&1|egrep "SONAME|File format")' \; |grep -v SONAME|grep -v 'not recog'|cut
-d: -f1|xargs equery -C b|cut -d' ' -f1|sort -u

producing the following list:

app-arch/p7zip-4.30
app-emulation/wine-20050930
app-office/openoffice-bin-2.0.0
app-text/ghostscript-7.07.1-r10
dev-java/libreadline-java-0.8.0-r1
dev-lang/ocaml-3.08.4
dev-lang/perl-5.8.7-r3
dev-lang/python-2.3.5
dev-lang/python-2.4.2
dev-lang/tcl-8.4.11
dev-lang/tk-8.4.11
dev-libs/elfutils-0.118
dev-libs/klibc-1.1.1
dev-ml/lablgl-1.00
dev-ml/lablgtk-2.6.0
dev-perl/Compress-Zlib-1.41
dev-perl/Crypt-SSLeay-0.51
dev-perl/Digest-SHA1-2.10
dev-perl/HTML-Parser-3.46
dev-perl/Locale-gettext-1.05
dev-perl/Net-DNS-0.53-r1
dev-perl/Net-SSLeay-1.25
dev-perl/Socket6-0.18
dev-perl/XML-Parser-2.34
dev-python/aspell-python-1.1
dev-python/celementtree-1.0.5
dev-python/ctypes-0.9.6
dev-python/imaging-1.1.5
dev-python/numeric-24.2
dev-python/pyopengl-2.0.1.09
dev-python/python-biggles-1.6.4
dev-python/python-fchksum-1.7.1
dev-python/pyxml-0.8.4
dev-python/wxpython-2.6.1.0
dev-util/valgrind-3.1.0
media-libs/allegro-4.2.0
media-libs/fmod-3.74
media-libs/ladspa-cmt-1.15
media-libs/ladspa-sdk-1.12-r2
media-libs/libmpeg3-1.5.2-r2
media-libs/win32codecs-20050412
media-sound/lilypond-2.5.2
media-video/vlc-0.8.4a
net-fs/autofs-4.1.3-r4
net-p2p/azureus-bin-2.3.0.4
net-www/adobesvg-3.01
perl-core/DB_File-1.814
perl-core/Digest-MD5-2.33
perl-core/MIME-Base64-3.05
perl-core/Storable-2.15
perl-core/Time-HiRes-1.82
sys-apps/file-4.16
sys-apps/help2man-1.35.1
sys-apps/iproute2-051007
sys-apps/pciutils-2.2.0-r1
sys-apps/portage-2.1_pre2
sys-libs/glibc-2.3.5-r3
sys-libs/libcap-1.10-r5
x11-base/xorg-x11-6.8.2-r6
x11-libs/qt-4.0.1

I'll try to file bugs with patches (when possible, like Gergan did)

in Gentoo, wouldnt revdep-rebuild solve this ?

Hm no, how is this supposed to be handled from revdep-rebuild?

because I thought revdep check (recursive) consistency of all libraries
returned by ldd calls on every binary files (or at least binaries declared in
manifests of ebuilds).

But I am quiet Gen newb (since march 2005), and never checked internal engine
of revdep ... and when I readed your first report, I thought that ... revdep
should point your problems without being able to solve it ... just tell me if
your grep still provide the same list, and if the same day revdep (maybe with
some options) does not complain, then I am wrong.

I have not tested the Dick's script I have other ways to test this.
Some explanation is probably needed - revdep-rebuild uses ldd, which
effectively resolves the libraries to the best of its knowledge and returns the
results.
This bug tracks libraries, which don't have proper soname-tags, which is, as it
says a tag in the library, which is versioned.
Now if this particular tag does not exist, it will default to the name of the
library.
Where is the problem? for example ffmpeg didn't have such tag and all its
libraries  had the default "name.so" as a soname tag.
Now let us assume you have updated your ffmpeg to the next version which would
not be api/abi compatible.
ldd and accordingly revdep-rebuild would test the libararies and executables,
which link against ffmpeg libraries, which in turn on their side have a
NEEDED-tag which says "name.so" - so in turn the linker would not find a
problem and would not report it to revdep-rebuild.
Now in the correct linux way the first version of the library should be
"name.so.1" as soname-tag for example, there should be also link name.so ->
name.so.1 and so on. And all libs and exes, which link against it would have
had NEEDED tag name.so.1,
But what  really matters is that after this hypothetical incompatible update
the new soname tag of the new library would be name.so.2 the correct link would
be name.so -> name.so.2 and so on.
But what would happen is that the lib or exe, which linked against name.so.1
would be cought from ldd and revdep-rebuild as they could not find name.so.1
anymore and would spit an error.

(In reply to comment #5)
> This bug tracks libraries, which don't have proper soname-tags, which is, as it
> says a tag in the library, which is versioned.
> Now if this particular tag does not exist, it will default to the name of the
> library.

I know bits of that because I have deved a lib last year ... I see what tag you
talk about:

-shared -Wl<deps>,-soname,foobar,[-rpath,foobars]

(from my makefile which inherits version NUMER from <I forgot where but it does
it>)

> Where is the problem? for example ffmpeg didn't have such tag and all its
> libraries  had the default "name.so" as a soname tag.
> Now let us assume you have updated your ffmpeg to the next version which would
> not be api/abi compatible.
> ldd and accordingly revdep-rebuild would test the libararies and executables,
> which link against ffmpeg libraries, which in turn on their side have a
> NEEDED-tag which says "name.so" - so in turn the linker would not find a
> problem and would not report it to revdep-rebuild.
> Now in the correct linux way the first version of the library should be
> "name.so.1" as soname-tag for example, there should be also link name.so ->
> name.so.1 and so on. And all libs and exes, which link against it would have
> had NEEDED tag name.so.1,
> But what  really matters is that after this hypothetical incompatible update
> the new soname tag of the new library would be name.so.2 the correct link would
> be name.so -> name.so.2 and so on.
> But what would happen is that the lib or exe, which linked against name.so.1
> would be cought from ldd and revdep-rebuild as they could not find name.so.1
> anymore and would spit an error.

before giving unfocussed tips, could you remind me what the libs DO, and what
they DONT DO:
- in the install script: proper linking using symlinks ?
- in Make stage: proper use of -Wl,-soname ?

Distribution level:
- install script could VERY EASILLY updated by a patch in the ebuild ...
- Makefiles are more tricky since they are live generated locally after run of
configure ... but I think it is possible for an ebuild to tweak something
between make and install: relink tge library, either using objdump then
re-assembling objects with apropriate values, or by creating a 'brand new
library' that would include code of 'vanilla one' also using apropriate -soname
and then you should have what you need.

In any case, it seems to me as gen-newb an upstream issue, THAT SHOULD BE fixed
at distribution level any way if upstreams dont react (like XMMS is known to be
deaf).

I now understand why solution to some recent xpdf bug was unemerge/reemerge,
and am quiet chocked to see that bug to be so old ...

Problem about Gentoo is that policy is quiet more flexible than Debian, so that
Gentoo mirors can accept projects that dont 100% comply the Gnu Coding
Standards ... thus is more subject to 'badly coded programs' since it has less
'strict verification filters' before stable validation IMHO.

But I am not 100% sure yet what the bug is exactly: missing tag ? tag not
updated in the source code of updated projects ? missing symlinks ?

cause revdep should be able to check all that ... or should be patchable to do
so ...

I am myself still shuffled about where to report:
- revdep ?
- gen respectuve ebuilds
- upstream ?

Could you give me an example of lib that actually have the problem ? or is it
about apps that are looking for the wrong lib number ? wine, zip, vlc ... I am
not fancy to open sources of xorg or OOo :P

lets try Valgrind:
4.0K -rwxr-xr-x 1 root root 1.8K 2005-12-21 09:01
/usr/lib/valgrind/x86-linux/vgpreload_core.so
 16K -rwxr-xr-x 1 root root  13K 2005-12-21 09:01
/usr/lib/valgrind/x86-linux/vgpreload_helgrind.so
 16K -rwxr-xr-x 1 root root  13K 2005-12-21 09:01
/usr/lib/valgrind/x86-linux/vgpreload_massif.so
 20K -rwxr-xr-x 1 root root  18K 2005-12-21 09:01
/usr/lib/valgrind/x86-linux/vgpreload_memcheck.so

are you telling that the binary should not be the 'root name' but a versionned
named pointed to by symlinks ? am I getting your point ?

before you do anything wrong, your little example script is horribly broken ...
SONAME only makes sense in things you will be linking against ... in other
words, stuff like plugins that only get dlopen()-ed have no need for SONAME ELF
tags

rather than using some readelf/objdump/strings hacks, just use `scanelf -S`

Nothing left here.