java-gnome-hackers

[java-gnome-hackers] --with-gcj-compile

[VEROK I. <vi...@in...>]

Hi!

I'm new to Java-GNOME, but I've been reading the mailing list
web archives for the last four months or so.  I run Debian unstable,
with Sun's 1.4.1_01 JDK, and ran into a few snags when finally
getting around to trying to get Java-GNOME to work.  I'd like
to have your opinion on these.

First, I checked out the CVS repository, did

./configure --with-libdir=/home/vi/incoming/java-gnome/lib --with-gcj-compile

because I want to eventually be able to compile stuff to
native binaries (not just class files).
Next came a

make all

which failed with about 370 error messages about missing classes.
I found that these could be made to go away by amending
java-gnome/src/Makefile's native-gnome and native-glade targets
in the following way:

native-gnome:	native-gtk $(GNOME_O)
	$(GCJ) -g -shared $(GNOME_O) -Ibuild-java/gtk -Ibuild-java/gnome -o ../lib/libGNOMEJar.so.${version}
                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

native-glade: $(GLADE_O)
	$(GCJ) -g -shared $(GLADE_O) -Ibuild-java/gtk --extdirs=/opt/jdk/jre/lib -o ../lib/libGladeJar.so.${version}
                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The --extdirs is needed because I killed two birds with one stone:
I have JDK 1.4.1 in /opt/jdk, and (on one hand) the Glade bindings
want JAXP (understandable), and (on the other hand) the SignalHandler
class wants to be a subclass of InvocationHandler, which is a Java
1.3 dependency (only satisfiable by /opt/jdk/jre/lib/rt.jar) introduced
quite recently by Tom Ball.  No flames, just an honest question:
was this really necessary?  I mean, from the free software angle.

Anyway, back to my build process: I also added an empty native-glade
target to test/Makefile to quench another complaint about a missing
target.  Having built the thing at last,

make install

didn't seem to want to work at all.  Even the top Makefile's install
target is horribly broken (the Makefile.in's
"install: @INSTALL_TARGETS@_install" line will never result in the
correct value of "install: gtk_install gnome_install native_install").
Also, specifying "--with-libdir" above does not influence the
generated Makefile at all, so even if this target worked as advertised,
everything would still be installed under /usr/local, not where I
wanted.  So I gave up on "make install", and copied the generated
lib directory by hand.

Then I discovered that I needed to edit build.xml's build-glade
target to say

<include name="org/gnu/glade/**"/>
                            ^^^

because the resulting glade.jar contained practically nothing
otherwise (I'm using Ant 1.5).  A recompile followed.

I have yet to get native compilation working.  I can get class files
using Java-GNOME, but my efforts to compile, say,
src/examples/glade/Examples1.java into a native binary have so
far all failed with hundreds of linking errors like

../lib/libGTKJar.so: undefined reference to `org::gnu::gtk::SpinButton::gtk_spin_button_get_adjustment(int)'

My command line for this compilation was scrounged from
src/Makefile and said:

gcj -fPIC -fjni -g -O --classpath=/usr/share/java/libgcj.jar:${JG}/gtk.jar:${JG}/gnome.jar:${JG}/glade.jar:. Example1.java -o Example1 -L../lib -lGTKJar -lGNOMEJar -lGladeJar -lGTKJava -lGNOMEJava -lGladeJava

I get the exact same error messages if the last three -l*Java
library references are omitted.  Any ideas?

Cheers,
Istvan

P.S.: Please CC me, I'm not subscribed to the list.

Re: [java-gnome-hackers] --with-gcj-compile

[Tom B. <Tom...@Su...>]

Hi Istvan,

I'm not a team leader, but may be able to address some of these
problems.  You unfortunately grabbed a snapshot of our project when it
is in the midst of a massive API overhaul -- we hope to have things
cleaned up soon for a '0.8' release soon, but aren't there yet.  While
we appreciate all the feedback, you may want to join our "announce"
mailing list and wait until that event to minimize your frustration.

On Wed, 2002-12-04 at 09:55, VEROK Istvan wrote:
> The --extdirs is needed because I killed two birds with one stone:
> I have JDK 1.4.1 in /opt/jdk, and (on one hand) the Glade bindings
> want JAXP (understandable), and (on the other hand) the SignalHandler
> class wants to be a subclass of InvocationHandler, which is a Java
> 1.3 dependency (only satisfiable by /opt/jdk/jre/lib/rt.jar) introduced
> quite recently by Tom Ball.  No flames, just an honest question:
> was this really necessary?  I mean, from the free software angle.

I'm a big supporter of open software, but not obsolete software.  While
gcj doesn't support Proxy (InvocationHandler is just an interface), it
will have to soon or risk splitting the Java platform.  I suppose I
could write something similar, but it would be very difficult as there's
a lot of good work in the proxy support classes.

If you know of a cleaner way to dynamically tie a method to a widget
using the org.gnu.gtk.event Listener interfaces, I'd love to hear it. 
I'm not tied to using dynamic proxies; it's just that we're using them
for exactly what they were designed to do.  Being lazy (one attribute of
a good programmer), I would rather use what exists than recreate it.

BTW, I'm rewriting the glade file parser to not use JAXP or SAX, so our
stuff won't have as many external dependencies. 

> Then I discovered that I needed to edit build.xml's build-glade
> target to say

> <include name="org/gnu/glade/**"/>
>                             ^^^
> 
> because the resulting glade.jar contained practically nothing
> otherwise (I'm using Ant 1.5).  A recompile followed.

Already fixed and checked in; you unfortunately caught a one-day window
where that was broken.

> I have yet to get native compilation working.  I can get class files
> using Java-GNOME, but my efforts to compile, say,
> src/examples/glade/Examples1.java into a native binary have so
> far all failed with hundreds of linking errors like
> 
> ../lib/libGTKJar.so: undefined reference to 
> `org::gnu::gtk::SpinButton::gtk_spin_button_get_adjustment(int)'

It sounds like our Java classes can't access their associated native
methods when compiled natively.  That's either a bug in our build (most
likely) or a gcj bug.  Please file a bug so we'll fix this.  Right now,
my understanding is that native compilation is a lower priority than
just getting things working again after all the recent design changes.

Tom