On Sun, 02 Dec 2007, Matthias Klose wrote: > Package: dpkg-dev > Severity: serious > Version: 1.14.12 > > 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 > > $ cat /var/lib/dpkg/info/libgcj-bc.shlibs > libgcj_bc 1 libgcj-bc (>= 4.2.1-1) > > I don't see any extra value to make a difference between /usr/lib64 > and /usr/lib on amd64 and ppc64.
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 works as long as the library is found exactly at the same path as the official symlink installed by libgcj-bc. However, as you noticed, there are cases where the library will be found somewhere else. You have the case with /usr/lib64 which is a symink and thus "dpkg -S /usr/lib64/libgcj_bc.so.1" doesn't return a package. I know openoffice.org had the case of the library being found where it actually is through the use of LD_LIBRARY_PATH becaused it linked to other java-related libraries that were in the same private directory (looks like on amd64 the library is not at the same place as on i386). 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. 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. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
