On Mon, 2006-03-27 at 18:30 +0200, Mark Wielaard wrote:
> On Sun, 2006-03-26 at 11:13 +0200, Michael Koch wrote:
> > > We use this invocation in java-gcj-compat:
> > >
> > > echo | gcc -shared -O2 -fPIC -o libjawt.so -Wl,-soname,libjawt.so -xc -
> > > -lgcjawt
> > >
> > > to create a binary-compatible replacement for Sun's libjawt.so. (Note
> > > that libgcj's version of libjawtgnu.so is called libgcjawt.so. I would
> > > like to change this and have all free runtime environments standardize
> > > on the name libjawtgnu.so).
> >
> > Why do we use another name then libjawt.so anyway? The lib is put into
> > $prefix/lib/classpath anyway and will never collide with SUNs. And we
> > dont need do such a hack as Tom mentioned for java-gcj-compat (which is
> > not really needed either, IMO). When classpath uses a different name
> > every runtime depending on it need do some hack to rename it to
> > libjawt.so again as real world apps do "System.loadLibrary("jawt");".
>
> It is kind of strange that real world apps do that. jawt isn't
> normal/jni library. You would expect that they have a jni library linked
> against the jawt library of the platform (and so jawt is loaded
> automatically when the shared library used by the application is
> loaded).
Right, that is the normal use case. But you still need a libjawt.so
binary in that case if you don't want to/cannot relink the
libjawt.so-using JNI parts of the app.
> But if real world applications do try to load it through such a
> call to System.loadLibrary() then it makes sense to name it libjawt.so.
> The only disadvantage to this might be that we don't want to clash with
> other libjawt.so files on the system. I believe that was the original
> reason for going with libjawtgnu.so since it is specific to our gtk-peer
> implementation. Tom?
Yes but this is a libgcj problem that doesn't affect GNU Classpath:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20790
Tom
