On Sun, 02 Dec 2007, Matthias Klose wrote: > > > The gcj-4.X packages fail to build with this version of dpkg: > > > > > > dpkg-shlibdeps: failure: no dependency information found for > > > /usr/lib64/libgcj_bc.so.1 (used by > > > debian/gcj-4.3/usr/lib/gcc/x86_64-linux-gnu/4.3/ecj1). > > > dh_shlibdeps: command returned error code 512
Hum, /usr/lib64 is scanned after /usr/lib so it means that debian/gcj-4.3/usr/lib/gcc/x86_64-linux-gnu/4.3/ecj1 has a RPATH pointing to /usr/lib64 ... Is that true ? Is there a good reason for this ? > > I must say that I find the construction of the libgcj-bc package very > > fragile. It doesn't contain the library it's supposed to contain but only > > a symlink to the library which is contained in another package (libgcj8-1 > > on i386). > > This is done to build code which is independent of the libgcj > soversion (see /usr/lib/gcj/). On the contrary, that is rather stable > than fragile. What's the purpose of the package ? Avoiding to hardcode a version in build-depends ? Why can't you add this symlink+shlibs directly into libgcj8-1 ? Since the soname is different, it shouldn't create any problem. > > Why don't you ship the shlibs file in the package that provides the > > library ? > > > > On i386: > > libgcj8-1: /usr/lib/libgcj.so.81.0.0 > > > > If you had done that, you wouldn't not have had that failure because > > dpkg-shlibdeps fallbacks to the realpath of the library when the > > first match doesn't give back a package. > > It is shipped in the same package. libgcj_bc is a different library > than libgcjX-Y which is used when building with -findirect-dispatch. > You can better see this by looking at the libgcj_bc.so file in the > libgcj8-dev package. I don't follow you: $ dpkg -L libgcj-bc /. /usr /usr/lib /usr/share /usr/share/doc /usr/share/lintian /usr/share/lintian/overrides /usr/share/lintian/overrides/libgcj-bc /usr/lib/libgcj_bc.so.1 /usr/share/doc/libgcj-bc There's no library in that package. There's only the symlink and the shlibs. And the symlink points to a lib in libgc8-1: $ ls -al /usr/lib/libgcj_bc.so.1 lrwxrwxrwx 1 root root 12 2007-09-05 08:47 /usr/lib/libgcj_bc.so.1 -> libgcj.so.81 $ dpkg -S /usr/lib/libgcj.so.81 libgcj8-1: /usr/lib/libgcj.so.81 Granted there's another file libgcj_bc.so file in /usr/lib/gcc/i486-linux-gnu/4.2/libgcj_bc.so but it seems unrelated for our case. > > Anyway, I think I'll modify the code to not report a lib found though an > > official symlink like those (instead I'll resolve the directory symlink > > beforehand). Expect a fix later this week. > > Thanks. Many upstream build systems do hardcode /usr/lib64 for x86_64, > and /usr/lib32 is used as a synonym for /emul/<something> ... Resolving symlinks is not without problems however. Think of people with symlinks like "/usr -> /scratch/usr". So it's not easy to implement it properly. Ideally I should have some code that report all valid names that a file can have... but I don't know of any code doing that right now. You should consider fixing the problem of RPATH on your side too. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
