* Yuan Yijun <yuan.bbbush(a)gmail.com> [2005-04-28 14:31]:
But I still cannot run a swt program, with the
steps described in these documents. If --cp contains only my jar, gcj
prompts that it cannot find some class definitions which are in swt.
Things have changed upstream and I'm not sure if the instructions will
still be valid. Until we can finish up work on , I'm not sure how
easily things will work (but I could be way off on that ... I haven't tried
running an SWT app in a while).
If not specify -Djava.library.path, gcj prompts that it cannot find
libswt-pi-gtk-...so, which is not contained in libswt3-gtk2 rpm, but I
still can locate it from /usr/share/eclipse/configurations/...... Then
what do the class map.db files do? Would anyone please help me out?
The problem in a nutshell is that the JNI libraries (libswt-*.so) have been
moved _into_ the jar and are ripped out at runtime by OSGi. Until  is
fixed, users will each have the .sos in their writable homedirs. Please
note: the solution to this is *NOT* to run Eclipse as root! There is at
least one report  of that hanging a person's system (no, I'm not
entirely sure why that happened but it's in my queue).
.jar.so and .db files are completely unrelated here. The way we're
shipping natively-compiled java apps in FC4 involves compiling the jars to
shared libraries (we're tacking a ".so" onto the end of the filename of the
jar) and then creating a little map db of what classes are in what .jar.so.
If the map db is screwed up or the .jar.so can't be found, gij will simply
fall back to interpreting the bytecode.