Currently, binaries built with GCJ's "Binary Compatibility" ABI link
against the same SNAME 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 SNAME with each release, but
changing the SNAME itself breaks BC-ABI applications which would
otherwise be compatible. If the two ABIs are to continue to co-exist, we
need different SNAMEs 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 SNAME 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 SNAME.
This approach also has the side-benefit of ensuring that BC applications
only link against legitimate BC-ABI symbols.
Currently this is only enabled for linux systems. It may make sense to
enable it for other ELF platforms too.
K for trunk?
Bryce

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 SNAME 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 SNAME with each release, but
changing the SNAME itself breaks BC-ABI applications which would
otherwise be compatible. If the two ABIs are to continue to co-exist, we
need different SNAMEs 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 SNAME 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 SNAME.

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. 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 -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

Fri, Jul 14, 2006 at 03:59:08AM -0400, Jakub Jelinek wrote:
gcc -shared -fpic -xc /dev/null -Wl,-soname,libgcj_bc.so.1 -o libgcj_bc.so.1.0.0 -lgcj

Make that
gcc -nostdlib -shared -fpic -xc /dev/null -Wl,-soname,libgcj_bc.so.1 -o libgcj_bc.so.1.0.0 -lgcj
which creates even smaller and better dummy lib (after prelinking it will
never be CWed).

Jakub

Bryce McKinlay writes:
K for trunk?
I'm going to do some experimenting with this patch. Please wait a
couple of days.
Andrew.
.

Bryce McKinlay writes:
Currently, binaries built with GCJ's "Binary Compatibility" ABI link
against the same SNAME 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 SNAME with each release, but
changing the SNAME itself breaks BC-ABI applications which would
otherwise be compatible. If the two ABIs are to continue to co-exist, we
need different SNAMEs 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 SNAME 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 SNAME.

This approach also has the side-benefit of ensuring that BC applications
only link against legitimate BC-ABI symbols.

Currently this is only enabled for linux systems. It may make sense to
enable it for other ELF platforms too.

K for trunk?

It doesn't work for me. I end up with this:

rwxrwxrwx 1 aph aph 15 Jul 14 14:29 libgcj.so -libgcj.so.7.0.0*
lrwxrwxrwx 1 aph aph 14 Jul 14 14:34 libgcj.so.7 -libgcj_bc.so.1*
-rwxr-xr-x 1 aph aph 83942015 Jul 14 14:29 libgcj.so.7.0.0*

Note that this means 'gij' doesn't work, becasue it's linked against
libgcj.so.7, and 'gij' needs gcj::verifyClasses().

Andrew.

Andrew Haley writes:
Bryce McKinlay writes:
Currently, binaries built with GCJ's "Binary Compatibility" ABI link
against the same SNAME 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 SNAME with each release, but
changing the SNAME itself breaks BC-ABI applications which would
otherwise be compatible. If the two ABIs are to continue to co-exist, we
need different SNAMEs 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 SNAME 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 SNAME.

This approach also has the side-benefit of ensuring that BC applications
only link against legitimate BC-ABI symbols.

Currently this is only enabled for linux systems. It may make sense to
enable it for other ELF platforms too.

K for trunk?

It doesn't work for me. I end up with this:

rwxrwxrwx 1 aph aph 15 Jul 14 14:29 libgcj.so -libgcj.so.7.0.0*
lrwxrwxrwx 1 aph aph 14 Jul 14 14:34 libgcj.so.7 -libgcj_bc.so.1*
-rwxr-xr-x 1 aph aph 83942015 Jul 14 14:29 libgcj.so.7.0.0*

Note that this means 'gij' doesn't work, becasue it's linked against
libgcj.so.7, and 'gij' needs gcj::verifyClasses().

Hmm. Looks like this was a transient problem; I re-installed and it's
K.

I'll carry on testing. More later.

Andrew.

Bryce McKinlay writes:

K for trunk?

This is not K. It causes problems building RPMS. Like this:

error: Failed dependencies:
libgcj_bc.so.1()(64bit) is needed by mx4j-3.0.1-1jpp_9fc.x86_64

Jakub assures me his suggested change to your patch will fix this.

Andrew.

Jakub Jelinek wrote:
libgcj_bc.so.1.0.0 has that DT_NEEDED, but not libgcj_bc.so.
K, I understand. I'm trying this now.
Bryce

Fri, Jul 14, 2006 at 12:19:43PM -0400, Bryce McKinlay wrote:
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 -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.


>>Well, we already tried this approach. It doesn't work because if
>>libgcj_bc.so.1 is linked to libgcj.so.37, then the linker adds a
>>DT_NEEDED for libgcj.so.37 to any binaries that are linked with
lgcj_bc. The linker option is supposed to stop this
>>from happening, but it doesn't work.
>
>
>Even when libgcj_bc.so (i.e. the static link time dummy lib) doesn't
>have DT_NEEDED on libgcj.so.* at all?

How does libgcj.so.37 get loaded at runtime, then?

libgcj_bc.so.1.0.0 has that DT_NEEDED, but not libgcj_bc.so.

Try:

gcc -shared -fpic -Wl,-soname,libgcj_bc.so.1 -o libgcj_bc.so libgcj_bc.c
gcc -shared -fpic -nostdlib -Wl,-soname,libgcj_bc.so.1 -o libgcj_bc.so.1.0.0 -xc /dev/null -lgcj
ln -sf libgcj_bc.so.1.0.0 libgcj_bc.so.1

and then link some -findirect-dispatch samples, with s/-lgcj/-lgcj_bc/ on
the ld command line.

BTW, you need #include <stdlib.hin libgcj_bc.c.

Jakub

Jakub Jelinek wrote:
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 -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.

Well, we already tried this approach. It doesn't work because if
libgcj_bc.so.1 is linked to libgcj.so.37, then the linker adds a
DT_NEEDED for libgcj.so.37 to any binaries that are linked with
-lgcj_bc. The linker option is supposed to stop this
from happening, but it doesn't work.

Bryce

It doesn't build the QT peer. You need this:

Index:

(revision 115439)
(working copy)
@@ -79,7 +79,7 @@

## GCJ LCAL: encode the library path and use GCJ's library version
libqtpeer_la_LDFLAGS = -rpath $(gcjversionedlibdir) \
--version-info `grep -v '^\#' $(top_srcdir)//libtool-version`
+-version-info $(ver_current):$(ver_revision):$(ver_age)

BUILT_SURCES = $(libqtpeer_la_MC)

Fri, Jul 14, 2006 at 12:04:05PM -0400, Bryce McKinlay wrote:
Jakub Jelinek wrote:
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 -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.

Well, we already tried this approach. It doesn't work because if
libgcj_bc.so.1 is linked to libgcj.so.37, then the linker adds a
DT_NEEDED for libgcj.so.37 to any binaries that are linked with
-lgcj_bc. The linker option is supposed to stop this
from happening, but it doesn't work.

Even when libgcj_bc.so (i.e. the static link time dummy lib) doesn't
have DT_NEEDED on libgcj.so.* at all?

Jakub

Jakub Jelinek wrote:
Fri, Jul 14, 2006 at 12:04:05PM -0400, Bryce McKinlay wrote:

>Jakub Jelinek wrote:
>
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 -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.


>Well, we already tried this approach. It doesn't work because if
>libgcj_bc.so.1 is linked to libgcj.so.37, then the linker adds a
>DT_NEEDED for libgcj.so.37 to any binaries that are linked with
>-lgcj_bc. The linker option is supposed to stop this
>from happening, but it doesn't work.
>
>
Even when libgcj_bc.so (i.e. the static link time dummy lib) doesn't
have DT_NEEDED on libgcj.so.* at all?

How does libgcj.so.37 get loaded at runtime, then?

Bryce