Hi Tom, On Tue, 2005-09-06 at 20:50 -0400, Thomas Fitzsimmons wrote: > > It would be nice if the makefile would work without the need to copy the > > sources > > over. > > Yes, even better would be if the JAWT demo were built automatically > along with the other examples. But that requires extra build machinery > that's not in place yet.
That is the idea. But I didn't want to introduce that extra build machinery one day before the release. So I choose to make a self contained example that the user would have to compile/run by hand for 0.18. If someone wants to merge example/Makefile.am with example/Makefile.jawt.in that would be cool. > Yes, I'm currently sorting this out for libgcj and java-gcj-compat. Sun > puts libjawt.so in $JAVA_HOME/jre/lib/i386. To ensure that libjawt.so > is found automatically, Sun's java executable prepends > $JAVA_HOME/jre/lib/i386 to LD_LIBRARY_PATH then re-exec's itself within > the new environment. > > I've just added a java command to java-gcj-compat that does the same > thing only exec's gij instead of re-exec'ing itself. I am not sure I have to be impressed or appalled by this hack :) Would it by an idea for the runtime (libgcj or some other) to dlopen the installed jawt library with RTLD_GLOBAL set before opening any other jni library (or maybe dlopen with the full path to libjawtgnu.so with RTLD_GLOBAL as soon as dlopen on a jni library fails and then retry loading that jni library)? That way it seems the linker can resolve the jawt symbols without needing to explicitly opening the shared library itself. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
