Bug#462318: symbols to blacklist for arme

2008-02-01 Thread Raphael Hertzog 
Hello,

On Thu, 31 Jan 2008, Riku Voipio wrote:
 Is there a easy way to generate .symbols files for all library packages
 for a selected arch? I presume mole has some code to do that but the
 sources hide from me. This would make it possible to do a exhaustive
 search of arch-specific symbols.

http://svn.debian.org/viewsvn/qa/trunk/mole/worker/symbols.tester?rev=1732view=log

See also the live install in alioth:~hertzog/mole/

Basically unpack the package in a directory and run dpkg-gensymbols
-Punpackdir -ppackage -vversion -O

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/

Bug#462413: dpkg-shlibdeps: please special-case libgcj_bc.so.1

2008-02-01 Thread Raphael Hertzog 
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/