This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/12250] --disable-shared disables too much
- From: "bim2003 at basistech dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 11 Sep 2003 15:39:36 -0000
- Subject: [Bug libstdc++/12250] --disable-shared disables too much
- References: <20030911143133.12250.bim2003@basistech.com>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12250
bim2003 at basistech dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |UNCONFIRMED
Resolution|INVALID |
------- Additional Comments From bim2003 at basistech dot com 2003-09-11 15:39 -------
On Solaris, there is a sort of tri-state logic. You can build any of:
(1) a .a file containing files compiled -fPIC
(2) a .a file containing files not compiled -fPIC
(3) a .so file.
There are good reasons to want #1, and, as a result, for about 10 years people
working on Solaris have built these things.
In my case, I want to make binaries that are self-contained and don't depend on
a libstdc++.so. On the other hand, I want some of those binaries to be,
themselves, shared libraries. This requires a libstdc++.a that contains .o
files created with -fPIC.
On Intel, this doesn't come up, because -PIC is optional, and so the
standard .a that results from a --disable-shared configuration can be used as
part of the build of a shared library. On sparc, some people I know just always
build with PIC, and some build two different archives.
I hope it isn't rude to repopen. If I still haven't convinced you, I'm not
planning to be a pest.