Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[platform-swt-dev] native compilation with GCJ3.3

The number of patches that I had to apply in GCJ 3.2 was quite high, but in
GCJ 3.3 (in CVS), the number has come down dramatically. SWT works perfectly
well, however, with GCJ. I use it extensively on Windows (minGW), while I
know there are many people using it on Linux.

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

src/org/eclipse/swt/custom/TableCursor.java:407:/*void */ boolean
traverse(Event event) { //X
src/org/eclipse/swt/custom/TableCursor.java:413:
return true; //X
src/org/eclipse/swt/custom/TableCursor.java:416:        return true; //X

javac does not complain about this, but GCJ does.

The following problem is unclear to me:

src/org/eclipse/swt/custom/DisplayRenderer.java:64://X  LineCache lineCache
= parent.internalGetLineCache();
src/org/eclipse/swt/custom/DisplayRenderer.java:92://X
selectionBackgroundWidth = Math.max(getClientArea().width,
lineCache.getWidth());

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

src/org/eclipse/swt/internal/image/FileFormat.java:18://X ----> make sure
they're included when statically linking
	private static final Class WINBMP_FILEFORMAT = WinBMPFileFormat.class;
	private static final Class GIF_FILEFORMAT = GIFFileFormat.class;
	private static final Class WINICO_FILEFORMAT = WinICOFileFormat.class;
	private static final Class JPEG_FILEFORMAT = JPEGFileFormat.class;
	private static final Class PNG_FILEFORMAT = PNGFileFormat.class;
src/org/eclipse/swt/internal/image/FileFormat.java:24://X <----

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

src/org/eclipse/swt/internal/Library.java:104://X
System.loadLibrary (newName);
src/org/eclipse/swt/internal/Library.java:109://X
System.loadLibrary (newName);

I've done a complete application where the GUI is made with SWT, the
middleware is apache-xmlrpc, and the remote database mySQL. The users are
really happy with the outcome, and the application has been very stable up
till now.

Now, in order to reduce the amount of retrofitting needed, to upgrade to new
SWT versions, is it possible to add these static references in SWT? Is it
possible to adapt the loadLibrary call, so that it looks if it's part of an
executable (and don't load a library in such case)?  For the other issues,
I'll deal with the GCJ group and work with them to get the
GCJ-specifications better in line with javac. At present, there are more
pressing issues, but I guess there will be time in the next few weeks to
address one or more of these issues.



Back to the top