This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Build libjava as two separate gorillas on Windows.
- From: Bryce McKinlay <bmckinlay at gmail dot com>
- To: Dave Korn <dave dot korn dot cygwin at googlemail dot com>
- Cc: Java Patches <java-patches at gcc dot gnu dot org>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 3 Sep 2009 14:24:31 +0100
- Subject: Re: [PATCH] Build libjava as two separate gorillas on Windows.
- References: <4A96FE5C.9070406@gmail.com>
On Thu, Aug 27, 2009 at 10:45 PM, Dave
Korn<dave.korn.cygwin@googlemail.com> wrote:
> ?The weakness is that it systematically ignores the whole USE_LIBGCJ_BC
> thing. ?I didn't approach that yet because I'm not 100% clear what's going on
> with it. ?I /think/ that libgcj_bc.la is basically a version of libgcj
> compiled with the binary abi, but there's all this stuff in the makefile about
> a dummy library and making a link to the real libgcj, so maybe I don't
> actually need to do anything except extend the specs handling a bit. ?Advice
> eagerly accepted here.
Dave,
The libgcj_bc library is a dummy library that is needed due to the way
that shared library versioning (ie soname) works on ELF systems. It
contains no actual code, just a bunch of symbols that BC compiled
applications can link against instead of linking libgcj.so directly.
This means that those BC-compiled binaries will continue to work when
the underlying libgcj is updated to a new version with a new soname.
(If all applications were BC compiled, it wouldn't be necessary - we
could just avoid changing libgcj's soname)
I don't know a lot about DLL versioning on Windows, but I suspect that
libgcj_bc may not be required and shouldn't be built on that platform.
Bryce