It's useful but inconvenient to produce gcj-compiled executables linked to a
static libgcj.a archive, but dynamic libc etc.
The typical workarounds are:
- Configure with --disable-shared
- Remove libgcj.so from $prefix/lib
- Use -static and forgo a dynamic libc
A dynamic libgcj should remain the default, as it is recommended and will become
easier to deploy as the binary compatibility ABI is inplemented and libgcj.so
becomes prepackaged on popular distributions.
One suggestion is to name this flag -static-libgcj, similar to gcc's -static-libgcc.
I would say this should also happen for libstdc++ also because it has the same issues when it
comes to ABI as libgcj but that would be definting the perpose of shared libraries, right?
Perhaps. libstdc++ does have a bit more ABI stability than libgcj at this time,
though. I'd be inclined to not have a -static-libstdc flag unless there are g++
users requesting it. I don't know if there are.
Closing as won't fix as the Java front-end has been removed from the trunk.