Re: configure --disable-shared

[Erik Poupaert <erik dot poupaert at chello dot be>]

> 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.

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.

> There certainly have been problems with --disable-shared on Linux in
> the past.  It's not a standard way to build, and it's impossible to
> support the whole language this way.

It is funny that these inferior and non-standard -- statically linked -- GCJ/mingw binaries can be deployed anywhere. I have them running on win98, win98ME, NT4, win2K, winXP ... they run everywhere, without the slightest problem (as long as windows service packs have been installed). On linux, they don't work anywhere properly.

I wonder by what miracle the whole language was supported this way on win32?

I guess Ranjit and Mohan managed to pull of a theoretically impossible trick. ... and now my SWT user interfaces work at least on windows; we'll probably have to wait until someone pulls off the same impossible trick of non-standard and inferior, but operable, executables on linux.