Hi Dalibor,
----- Original Message ----- > > Does that happen with Qt-awt or Xlib awt or both? It happens only with Qt-awt. I solved this issue by adding a couple of compile options in $KAFFE_HOME/libraries/clib/awt/qt/Makefile. The original CXXFLAGS in the Makefile was: CXXFLAGS := $(CXXFLAGS) $(QT_CXXFLAGS) After the modification: CXXFLAGS := $(CXXFLAGS) $(QT_CXXFLAGS) -fno-exceptions -fno-rtti -DQWS What I added was those options in CFLAGS. Because the source files in QT directory are '.cc', only CXXFLAGS are applied during build. If '-fno-rtti' is not defined during compile, link error happens when java vm trys to load libqte.so. (The embedded-QT library, libqte.so, is also built with '-fno-rtti' option.) I forgot to report this issue, and really forgot the issue itself. :( Sorry for bothering you. > > So my conclusion is that while kaffe's has a bug when > compared to JDK 1.4.1 with respect to directly > defining java.libraries.path (and you probably > shouldn't do that), it is not behaving significantly > worse on this example. It implements Java 1.2 > semantics with respect to Runtime.loadLibrary(). > > What you seem to want is the JDK 1.1 semantics, where > the library is apparently automatically searched for > in common library directories like /usr/lib. I'd like > to hear some comments if people think that would be a > desirable feature. > > I am not in favor of Java 1.1 semantics, because > LD_LIBRARY_PATH works, is what Java 1.2 says we should > do (in Java Class Libraries 2nd Ed. Vol 1 Supplement, > the API spec for Java 1.4.1 is very vague), and allows > more flexibility with respect to testing with > different library versions (just change the path in > LD_LIBRARY_PATH). Of course, if you disagree, I'd like > to hear about it. I also think LD_LIBRARY_PATH is enough to handle libraries. Thank you for the thorough tests. Best Regards, KIM, Seongbeom. _______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
