Re: [PATCH] Build libjava as two separate gorillas on Windows.

[Dave Korn <dave dot korn dot cygwin at googlemail dot com>]

Bryce McKinlay wrote:
> On Thu, Aug 27, 2009 at 10:45 PM, Dave Korn 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)

  TYVM Bryce :)

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

  Well, we might decide it's a nice feature to use on windows as well,
currently any java executable will end up with an embedded reference to
cyggcj-11.dll, and the version tag will occasionally change.  We deal with
that by keeping old library versions around because we don't have symbol
versioning, but either/and/or both of those may potentially be improved in the
future, and we could probably make the same kind of
proxying-through-a-library-that-doesn't-change-soname work on Windows.

  But that's a project for another day, and would necessitate adding a
libgcj-noncore_bc.la as well as libgcj_bc.la.

  BTW, in case you didn't spot the new thread yet, I already respun this patch
and posted the final submission:

http://gcc.gnu.org/ml/gcc-patches/2009-08/threads.html#01679

    cheers,
      DaveK