This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++
- From: "bkoz at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 28 Jan 2009 03:25:22 -0000
- Subject: [Bug libstdc++/28811] --with-pic vs static libraries and libstdc++
- References: <bug-28811-7667@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #15 from bkoz at gcc dot gnu dot org 2009-01-28 03:25 -------
Here are my thoughts on how to fix this. None of the presented options is
workable, IMHO.
The preferred end goal is to only have the compatibilty.cc and
compatibilty-ldbl.cc objects in the shared library, and not in the static
library.
1) HJ's suggestion in #11, to remove compatibility.cc and compatibility-ldbl.cc
archive files from the static library via binutils trickery. Alan responded
that the capability is limited to removal, but that's what is wanted here. My
preference is to not build the (incorrect) object file in the first place.
2) Adding -DSHARED to LTCXXCOMPILE in src/Makefile.am. This doesn't
disambiguate between shared and static objects though. Out.
3) Custom rules for compatibility.o and compatibility.lo in src/Makefile.am.
the *.lo rule adds -DSHARED and the *.o rule does not. Replace PIC with SHARED
in compatibility.cc
This mostly works, as long as the *.o rule is compiled after the *.lo rule.
Seems weak to rely on this ordering though.
4) somehow stuff the compatibility objects into a separate, shared-library-only
convenience library
?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811