Re: [platform-swt-dev] native compilation with GCJ3.3

[Tom Tromey <tromey@xxxxxxxxxx>]

>>>>> "Erik" == Erik Poupaert <erik.poupaert@xxxxxxxxx> writes:

Erik> There is still one patch needed, related to the fact that GCJ and javac
Erik> follow a slightly different compiler specification:
Erik> [ ... ]

I believe this is a gcj bug.  Could you file a gcj PR for this (if you
didn't already?  I forget if you did).

Erik> The following problem is unclear to me:
Erik> src/org/eclipse/swt/custom/DisplayRenderer.java:64://X  LineCache lineCache
Erik> = parent.internalGetLineCache();
Erik> src/org/eclipse/swt/custom/DisplayRenderer.java:92://X
Erik> selectionBackgroundWidth = Math.max(getClientArea().width,
Erik> lineCache.getWidth());

Probably more gcj bugs.  I can't be sure since there isn't enough info
here.

Erik> Then, there is the fact that the FileFormat operates through
Erik> reflection, and that the linker will fail to include these
Erik> classes, when statically linking.  It can be solved by adding
Erik> otherwise harmless references to the classes that need to be
Erik> linked:

I think you should do this in your application or something like that.
It's a bit weird to try to add this to SWT.  For one thing, unless the
SWT developers are building with gcj and statically linking, they
won't have any way to know how to maintain this code.

Erik> A last patch is needed in order to integrate the jni-library
Erik> into the executable (to have one single, self-contained
Erik> executable). It requires of course to disable the loadLibrary
Erik> calls:

Could you instead experiment with libltdl's prelinking feature?
In theory this would let loadLibrary succeed by telling libltdl that
the required JNI library was linked in statically.

Tom