Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 98715 - meta-bug for tracking the public libraries without the soname-tag in them
Summary: meta-bug for tracking the public libraries without the soname-tag in them
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Quality Assurance Team
URL:
Whiteboard:
Keywords: Tracker
Depends on: 98565 98573 98717 100050 125971 126866 132381 132417
Blocks:
  Show dependency tree
 
Reported: 2005-07-11 16:17 UTC by Gergan Penkov
Modified: 2006-12-03 06:15 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gergan Penkov 2005-07-11 16:17:14 UTC
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.
Comment 1 Dick Marinus 2005-12-27 13:21:11 UTC
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)
Comment 2 DEMAINE Benoît-Pierre, aka DoubleHP 2006-02-15 08:05:01 UTC
in Gentoo, wouldnt revdep-rebuild solve this ?
Comment 3 Gergan Penkov 2006-02-15 08:26:36 UTC
Hm no, how is this supposed to be handled from revdep-rebuild?
Comment 4 DEMAINE Benoît-Pierre, aka DoubleHP 2006-02-15 08:31:35 UTC
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.
Comment 5 Gergan Penkov 2006-02-15 08:59:27 UTC
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.
 
Comment 6 DEMAINE Benoît-Pierre, aka DoubleHP 2006-02-15 10:51:26 UTC
(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 ?
Comment 7 SpanKY gentoo-dev 2006-03-12 19:18:19 UTC
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`
Comment 8 Jakub Moc (RETIRED) gentoo-dev 2006-12-03 06:15:10 UTC
Nothing left here.