[Bug target/21277] Runtime error with C++ shared library and --disable-shared

[info at yourkit dot com]

------- Additional Comments From info at yourkit dot com  2005-05-02 09:25 -------
> 5 MB uncompressed for 32-bit, 6 MB uncompressed for 64-bit!

Of course it's not a show stopper, but given 2-3M total packed size of the
distribution, we'd prefer not to double it. Furthermore, the approach always
worked for 32 bit.

> There is nothing wrong in the current behavior of --disable-shared: it builds
static libraries the way static libraries should be built.  Your practice of
building shared libraries with a compiler configured with --disable-shared looks
far more questionable to me; if I were to change something, I'd simply reject
-shared in that case.  Note for example that a shared libgcc is required on
Solaris for exception propagation accross shared libraries.

Actually, instead of --disable-shared we were successfully using gcc compiled
without this flag, specifing appropriate *.a on linking stage. --disable-shared
only makes compile [command line] more straightforward, not letting compiler
using .so's instead.

There's absolutely nothing illegal in static linking with a shared library other
libraries that it uses. The intention is to make resulting shared library
loadable on every target machine with no regard to availablity of shared
libraries, and make the library as small as possible.

The approach works fine for 32 bit on Solaris. And it is definetely a bug that
it doesn't do so for 64 bit.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21277