Re: AWT with static gcj

[Marco Trudel <mtrudel at gmx dot ch>]

Tom Tromey wrote:
> > > > > > "Marco" == Marco Trudel <mtrudel@gmx.ch> writes:
>
> Marco> Well, actually I really mean it. But I would expect to either get a
> Marco> libgtkpeer.so or that the gtkpeer stuff will be pulled into the
> Marco> executable when using AWT.
>
> Yeah.  There are 2 problems.
>
> 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. 

Yes, I know. The other problem - beside that there are no windows 
maintainers - that stops GCJ from living out its full potential and 
being widely (really widely) used.
I hope you forgive me that I will keep staying around and keep bugging 
the list with questions to get GCJ running on linux and windows at the 
same level (at least from my point of view).
I will help where I can and do what I can, but currently I'm not yet 
very familiar with the inside of GCJ, so there probably will be some 
more emails...


> 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...

You forget the windows world and standard java programmers out there ;-)
GCJ currently only works in disable-shared mode on windows and AWT/Swing 
is unfortunately widely used there.
To get GNU classpath AWT/Swing working on windows, I first had to get it 
working on a disable-shared mode on linux... Step by step...


> The other problem is that even if this code were included in libgcj.a,
> it still wouldn't end up in your program, since nothing would pull in
> the various symbols in the JNI code.  And, loadLibrary would still
> fail.  So you would wind up having to do libltdl-style prelinking, or
> its equivalent, anyway.

I'm not familar with libltdl. Was you basic idea to replace libgtkpeer.a 
with an own written shared library that dlpreopens the original 
libgtkpeer.a?
Or do I understand you wrong? Did you mean to include the library into 
the final executable somehow?


> I'm not averse to some or all of this happening ... by which I mean I
> would approve a clean patch :-)

The word "clean" probably is a problem here. As I said, I hacked the 
Makefile in the gtkpeer directory. And to get this all clean, the file 
that loads libgtkpeer.a should be altered so that it loads a .so file 
when in disable-shared mode.
I currently don't have the knowledge on how to do that, sorry. Maybee at 
a later time, I will keep working on the libgtkpeer thing...


Marco