Bug#453885: dpkg-shlibdeps changes can't track symlinks (/usr/lib, /usr/lib64)
On Mon, 03 Dec 2007, Matthias Klose wrote: 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 ? maybe not; but this kind of thing is hardcoded upstream, so you'll see this in other packages as well. I know we're not going to clean all RPATH magically, but it might still be nice to clean them progressively. :) I'll still fix the generic problem that dpkg-shlibdeps has been seeing. Since the soname is different, it shouldn't create any problem. no, then all the -gcj packages would depend on libgcj8-1, not on libgcj-bc. That's not true. You can perfectly put a shlibs file in libgcj8-1 that's going to generate a dependency on libgcj-bc for binaries linked to libgcj_bc.so.1. Please consider this approach. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#453885: dpkg-shlibdeps changes can't track symlinks (/usr/lib, /usr/lib64)
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]
Bug#453885: dpkg-shlibdeps changes can't track symlinks (/usr/lib, /usr/lib64)
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/
Bug#453885: dpkg-shlibdeps changes can't track symlinks (/usr/lib, /usr/lib64)
Raphael Hertzog writes:
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 ?
maybe not; but this kind of thing is hardcoded upstream, so you'll see
this in other packages as well.
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.
no, then all the -gcj packages would depend on libgcj8-1, not on
libgcj-bc.
From the patch introducing libgcj_bc.so:
Currently, binaries built with GCJ's Binary Compatibility ABI link
against the same SONAME as binaries built with the C++ ABI. This is
problematic because changes to the Java class libraries frequently
break C++ ABI compatibility: we need to bump the SONAME with each
release, but changing the SONAME itself breaks BC-ABI applications
which would otherwise be compatible. If the two ABIs are to continue
to co-exist, we need different SONAMEs for them.
This solution works by creating a shared library called libgcj_bc.so
which contains empty, fake declarations of all the symbols that
BC-ABI applications are allowed to reference in libgcj. At compilation
time, if -findirect-dispatch is specified, gcj will link with -lgcj_bc
instead of -lgcj. The linker will find libgcj_bc.so, which has an
SONAME of libgcj_bc.so.1.
However, libgcj_bc.so.1 itself is actually a symlink to the real
libgcj.so. So at runtime, the dynamic linker loads the real library to
resolve the libgcj_bc.so.1 SONAME.
This approach also has the side-benefit of ensuring that BC
applications only link against legitimate BC-ABI symbols.
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.
Special-casing /lib{32,64} and /usr/lib{32,64} would be very welcome.
Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
