AWT with static gcj

Scott Gilbertson scottg@mantatest.com
Fri Sep 22 16:59:00 GMT 2006


Tom Tromey wrote:
> One is that static linking is not really fully maintained.  It is more
> something that works just well enough for the folks who use it to use
> it for their tasks.  It doesn't see a lot of active maintenance, and
> since the folks currently relying on static linking don't, as far as I
> know, use AWT...

Actually, some of us do, but in my case only with the xlib peers, not gtk.
The xlib peers don't do any library loading, so as long as you force the
xlib classes to link (I do that by linking the whole lib-gnu-awt-xlib.a)
everything works.  Of course, if you use xlib peers, you don't get very much
of AWT, because they're lean and mean (good for embedded systems, which also
typically need a static build).  It's also linux-only, I guess.

Thinking out loud about fully-static builds with gtk peers (which used to
work, a long time ago), I wonder whether the gtk toolkit could have a
subclass (GtkStaticToolkit?), built only for the static library, that
assumes things are linked in rather than loading libraries.  Maybe that
would involve sticking "System.loadLibrary("gtkpeer");" and
"System.loadLibrary("gconfpeer");" in a pair of GtkToolkit methods that are
used all over the place, and overriding those in the subclass rather than
calling loadLibrary directly.  The subclass could also maybe include a bunch
of "private static Class cl1 = the.package.TheClass.class;" statements to
ensure that things get linked.  That way there would be an obvious place to
specifically maintain the peers for static builds, without too much
disturbance of the "normal" toolkit.



More information about the Java mailing list