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). 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? Cheers, Mark
signature.asc
Description: This is a digitally signed message part
