On Thu, 24 Jan 2008, Raphael Hertzog wrote: > Hi, > > On Thu, 24 Jan 2008, Matthias Klose wrote: > > Currently dpkg-shlibdeps emits wrong-leading warnings for packages > > linked against libgcj_bc.so: > > > > dpkg-shlibdeps: warning: debian/ecj-gcj/usr/bin/ecj-gcj shouldn't be linked > > with libgcj_bc.so.1 (it uses none of its symbols). > > dpkg-shlibdeps: warning: debian/ecj-gcj/usr/bin/ecj-gcj shouldn't be linked > > with libpthread.so.0 (it uses none of its symbols). > > dpkg-shlibdeps: warning: debian/ecj-gcj/usr/bin/ecj-gcj shouldn't be linked > > with librt.so.1 (it uses none of its symbols). > > dpkg-shlibdeps: warning: debian/ecj-gcj/usr/bin/ecj-gcj shouldn't be linked > > with libz.so.1 (it uses none of its symbols). > > dpkg-shlibdeps: warning: debian/ecj-gcj/usr/bin/ecj-gcj shouldn't be linked > > with libdl.so.2 (it uses none of its symbols). > > > > If libgcj_bc.so.1 is found as a dependency, only the symbols built > > from the libgcj_bc.c file should be evaluated. > > Sorry, I don't understand what you mean. Can you give some more details?
After a quick chat on IRC, it looks like the core problem might be that libgcj_bc.so.1 in fact has a SONAME libgcj.so.X since it's just a symlink... At build time, it links with a libgcj_bc.so that contains just the official symbols but at run time the "official symbols" are looked up in another library... because libgcj_bc.so.1 is a symlink to that library. The differing SONAME are probably the root cause of this problem. We should find a way to register both SONAME as aliases to avoid this. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
