Mon May 26 18:35:00 GMT 2003
On Mon, 26 May 2003, Erik Poupaert wrote:
> > You can get the same effect from a shared build by
> > removing the libgcj.so symbolic link from your install tree, in which case
> > ld will fall back on libgcj.a.
> I've tried today. It works, but only in part. It helps to solve the
> problem with the incompatible libgcj.so, but it doesn't do anything to
> get rid of the incompatible libgcc_s.so.1 dependency.
Hmm, libgcc_s is quite stable. Are you installing on Linux hosts with an
older libgcc_s in /lib? Or none at all? (In that case, I like Mohan's
suggestion of distributing libgcc_s.so with your application.)
You could try the same trick with libgcc_s.so, but it seems dangerous to
me. There are good reasons libgcc_s must be a shared library. EH relies
> It is really a combination of problems. On the one side, there is the
> fact that none of this is backwards compatible. GCJ binaries don't work
> anywhere on existing linux installations. They simply can't resolve
> their dependencies. On the other side, the bug in --disable-shared prevents
> solving the problem by linking statically.
Binaries compiled with a library libfoo.so.i.j should run with
libfoo.so.i.k where k >= j. (libgcj is an exception, since it does not
yet export a stable API.)
Downgrading libraries simply won't work. For instance, you couldn't
expect to build on RH 8 and move the binaries to RH 7.3.
To completely static link an executable, you will also be linking
libc/libm/libpthread into your application. You really don't want to do
> I wonder by what miracle the whole language was supported this way on win32?
It isn't. Win32 builds exhibit the same difficulties as static Linux
builds. (Surely you're not claiming your Java application exercises the
More information about the Java