configure --disable-shared

Jeff Sturm
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 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, but it doesn't do anything to
> get rid of the incompatible 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 with your application.)

You could try the same trick with, but it seems dangerous to
me.  There are good reasons libgcc_s must be a shared library.  EH relies
on it.

> 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 should run with 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
"whole language"?)


More information about the Java mailing list