[boehm-gc] Import 6.3 alpha 1

[Jeff Sturm]

On Thu, 31 Jul 2003, Bryce McKinlay wrote:
> > This is an example of what blocks us from using gcj from "real world"
> > applications.
>
> Got any examples? Not that I don't believe you, but I'd like to
> understand the problem better.

Off the top of my head?  Hmm... I've seen examples similar to the one I
posted in JDBC drivers, those trying to support JDBC1/2 from a single
class archive.  I could swear pgsql used to do those sort of tricks.

Here's a tiny example, taken from code we maintain.

  String driver = System.getProperty("jdbc.driver",
	"com.i33.testing.FakeDriver"));

FakeDriver is a mock pattern object that only appears in our test builds,
not production code.  Some well-intentioned maintenance programmer
replaced that with:

  String driver = System.getProperty("jdbc.driver",
	FakeDriver.class.getName());

It went undetected until I tried a gcj build, which failed on a link
error.

This code was easy to fix.  On the one hand I'm happy that gcj alerted me
to the dependency.  On the other it ought to have worked anyway (at least
until this line of code was executed, at which time NoClassDefFoundError
or something is thrown).

Native-code compilation with gcj works as though every class explicity
named in the source code is loaded at build time, though class
linkage/initialization is deferred to run time.  It sometimes goes too
far.  I realize -fno-assume-compiled=... makes it easier, but support for
that is incomplete.

For another example, try building a project like ant or dom4j from the
main source distribution (not rhug).  Build either from .jar archives or
source to native code.  It's frustratingly difficult.

I'd be happy if there were some gcj flags that work 99% of the time when
doing a naive compilation of third party sources or jar archives to native
code, even if not the default flags.  Maybe finishing -fno-assume-compiled
will be good enough.

Jeff