This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: [java] RFC/RFA: libgcj_bc.so.1
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Bryce McKinlay <mckinlay at redhat dot com>
- Cc: Java Patches <java-patches at gcc dot gnu dot org>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Ulrich Drepper <drepper at redhat dot com>
- Date: Fri, 14 Jul 2006 03:59:08 -0400
- Subject: Re: [java] RFC/RFA: libgcj_bc.so.1
- References: <44B71F98.9020705@redhat.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Fri, Jul 14, 2006 at 12:37:44AM -0400, Bryce McKinlay wrote:
> 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.
This is fine.
> 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.
But this has a severe disadvantage. If /usr/lib*/libgcj_bc.so.1 is
a symlink to libgcj.so.37.0.0, then only libgcj.so.37 will be in ld.so.cache
and libgcj_bc.so.1 will not be there. So, whenever an application or
library has DT_NEEDED libgcj_bc.so.1 (i.e. it has been built with
-findirect-dispatch), the dynamic linker will need to do an actual
filesystem search for it. On the other side, if
/usr/lib*/libgcj_bc.so.1 is a symlink to
libgcj_bc.so.1.0.0 and /usr/lib*/libgcj_bc.so.1.0.0 is a dummy shared
library (
gcc -shared -O2 -fpic -xc /dev/null -Wl,-soname,libgcj_bc.so.1 -o libgcj_bc.so.1.0.0 -lgcj
), then both libgcj.so.37 and libgcj_bc.so.1 will be in ld.so.conf.
Jakub