Raphael Hertzog writes: > 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 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. > 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. 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. > 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> ... Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
