[kaffe] Is it a bug? System.loadLibrary() fails...

KIM, Seongbeom sbkim at mail.marusys.com
Wed Jan 15 20:01:01 PST 2003

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

The original CXXFLAGS in the Makefile was:

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.

More information about the kaffe mailing list