Re: [PATCH] [4.5 regression] Fix PR42811: java.lang.ExceptionInInitializerError in ecj1 and associated issues.

[Dave Korn <dave.korn.cygwin@googlemail.com>]

On 22/02/2010 10:12, Andrew Haley wrote:

>>   Bootstrapped and tested on i686-pc-cygwin; fixes PR42811 and doesn't cause
>> any further regressions (there are some preexisting fails that this makes no
>> difference to).  OK for head?
> 
> A couple of things:
> 
> 1.  Bounce the gc changes off gcSPLATnapali.hpl.hp.com .

  Certainly shall, I imagine Hans will be expecting me to.  (It'll take me
some work though, the patch doesn't apply cleanly against upstream cvs, I
already checked; I'll need to verify how much has changed and make sure the
patch is still correct wrt. any internals differences.)

> 2.  Is it really necessary to make the main program depend on a symbol
>     in libgcj-noncore when BC compiling?  Can't you make the libgcj
>     itself depend on libgcj-noncore?

  I probably could, in stage 1, but it would require a large amount of build
system hackery that I don't want to risk at stage 3.  The noncore dll already
depends on the core dll, so if I added a dependency the other way round we'd
have a circular loop.  You can only link a DLL if it's fully resolved
(critical difference from ELF DSOs there), so whichever one we tried to link
first, it would have missing imports from the other.  There is a way round
that, we could use 'dlltool' to build just an import stub library for one of
them separately, first, then fully link the other, generating its own import
library in the process that would let libtool link the original library in the
first place.  But... that would require having a complete list of exports (to
make a .DEF file), and we don't have such a list either, we just have a
version script with some pattern matches; so we'd have to build the dll fully
and find out which symbols did actually get hidden and which made visible ....
at which point we'd have an import library anyway.  So probably the only way
to make it work would be to invoke libtool twice for the same library, once to
build the core dll without this dependency, so that we can then link (and
fully resolve) the noncore dll, and once again after linking the noncore dll,
to relink a version of the core dll with the dependency against the noncore
one added this time round.  (On slightly deeper thought, it might be possible
to generate a fake import stub library, just for the purpose of linking the
core dll, with a single import for the one manually chosen symbol that I'm
using anyway, but I haven't tested that theory yet; I'm making it up as I type
here.)

  So, yeh, I've thought about it, because until I figured out a partitioning
which only had dependencies in one direction, I thought I was going to have to
do it that way all along, and avoiding having to do so was the reason I chose
to try and partition the libraries according to the dependencies between the
object files in the first place.  (That worked, so I stopped thinking about it!)

  If we can think of a non-ugly way of making a circular dependency between
the two libraries, we can change that in the future and stop adding this
dependency to executables without affecting binary compatibility in any way
either forward- or backward-, but I can't really envisage any actual benefits
from doing so, apart from things being a bit conceptually cleaner and nicer,
unless I've overlooked something?  (Do we have to ever worry about anyone
trying to link java applications using 'ld' directly and avoiding the gcj
driver and its specs?  I wouldn't have expected so!)

  Anyway, that's why I figured on taking the simple approach right now; it'll
work, and it's simple, and we can change it without problems in the future.

  Stage 3 probably isn't going to finish this week, but it probably isn't
going to last much longer either.  How about we commit this one now, as
insurance against the branch getting cut, but I also go ahead and see if I can
figure out how to get the dlltool-plus-fake-DEF-file trick working as well; if
I can get it to work while stage 3 is still running, we can revert the change
to the specs at the same time.  OK?

    cheers,
      DaveK