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]
