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

[KIM, Seongbeom]

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.