[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811 --- Comment #26 from Alec Ari --- To avoid fully recompiling GCC, I modified libstdc++-v3/configure (not .ac) and made the following change: --- a/libstdc++-v3/configure +++ b/libstdc++-v3/configure @@ -15014,8 +15014,8 @@ if test "$enable_shared" = yes; then glibcxx_compiler_shared_flag="-D_GLIBCXX_SHARED" else - glibcxx_lt_pic_flag= - glibcxx_compiler_pic_flag= + glibcxx_lt_pic_flag="-prefer-pic" + glibcxx_compiler_pic_flag="$lt_prog_compiler_pic_CXX" glibcxx_compiler_shared_flag= fi Special thanks to the guys in this thread, problem solved. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58638
[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811
Alec Ari changed:
What|Removed |Added
CC||neotheuser at ymail dot com
--- Comment #25 from Alec Ari ---
Created attachment 40087
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40087=edit
relocation X against symbol `Y can not be used...
I still have this problem, just ran git pull on master branch, this is my
configure line:
$ cd gcc && mkdir build && cd build
$ ../configure --prefix=/home//git-toolchain-bin/usr
--with-local-prefix=/home//git-toolchain-bin/usr
--with-native-system-header-dir=/home//git-toolchain-bin/usr/include
--disable-nls --disable-shared --disable-multilib --disable-libatomic
--disable-libgomp --disable-libmpx --disable-libquadmath --disable-libssp
--disable-libvtv --disable-libstdcxx-pch --enable-languages=c,c++
--disable-werror --without-isl --disable-libcilkrts --disable-libitm
--disable-libsanitizer --disable-lto --disable-gold
Replacing --disable-libstdcxx-pch with --disable-libstdcxx brings me this:
xg++: error: unrecognized command line option '-funconfigured-libstdc++-v3'
Adding/removing c++ from enabled languages seems to have no effect. Recompiling
Binutils (2.27 branch) with CFLAGS="-O2 -fPIC" and CXXFLAGS="${CFLAGS}" added
to configure line did not fix the issue (nor change it in any way) and
compiling GCC with that same option causes it to die much earlier.
This is as far as I've got so far trying to build a toolchain sysroot, very
close!
[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC|gcc-bugs at gcc dot gnu.org| Resolution|--- |FIXED --- Comment #24 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed
[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811 --- Comment #23 from __vic d.v.a at ngs dot ru --- What actual status of this bug is? Is it fixed or still not?
[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811 --- Comment #21 from Benjamin Kosnik bkoz at gcc dot gnu.org 2012-11-05 23:42:36 UTC --- Author: bkoz Date: Mon Nov 5 23:42:32 2012 New Revision: 193195 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193195 Log: 2012-11-05 Benjamin Kosnik b...@redhat.com PR libstdc++/28811 PR libstdc++/54482 * configure.ac (glibcxx_lt_pic_flag, glibcxx_compiler_pic_flag, glibcxx_compiler_shared_flag): New. Use them. (lt_prog_compiler_pic_CXX): Set via glibcxx_*_flag(s) above. (pic_mode): Set to default. (PIC_CXXFLAGS): Remove. * Makefile.am (PICFLAG, PICFLAG_FOR_TARGET): Remove. Comment. * libsupc++/Makefile.am: Use glibcxx_ld_pic_flag and glibcxx_compiler_shared_flag. Comment. * src/c++11/Makefile.am: Same. * src/c++98/Makefile.am: Same. * src/Makefile.am: Use glibcxx_compiler_pic_flag. * Makefile.in: Regenerated. * aclocal.m4: Same. * configure: Same. * doc/Makefile.in: Same. * include/Makefile.in: Same. * libsupc++/Makefile.in: Same. * po/Makefile.in: Same. * python/Makefile.in: Same. * src/Makefile.in: Same. * src/c++11/Makefile.in: Same. * src/c++98/Makefile.in: Same. * testsuite/Makefile.in: Same. * src/c++11/compatibility-atomic-c++0x.cc: Use _GLIBCXX_SHARED instead of PIC to designate shared-only code blocks. * src/c++11/compatibility-c++0x.cc: Same. * src/c++11/compatibility-thread-c++0x.cc: Same. * src/c++98/compatibility-list-2.cc: Same. * src/c++98/compatibility.cc: : Same. * testsuite/17_intro/shared_with_static_deps.cc: New. * doc/xml/manual/build_hacking.xml: Separate configure from make/build issues, add build details. Added: branches/gcc-4_7-branch/libstdc++-v3/testsuite/17_intro/shared_with_static_deps.cc Modified: branches/gcc-4_7-branch/libstdc++-v3/ChangeLog branches/gcc-4_7-branch/libstdc++-v3/Makefile.am branches/gcc-4_7-branch/libstdc++-v3/Makefile.in branches/gcc-4_7-branch/libstdc++-v3/configure branches/gcc-4_7-branch/libstdc++-v3/configure.ac branches/gcc-4_7-branch/libstdc++-v3/doc/Makefile.in branches/gcc-4_7-branch/libstdc++-v3/doc/xml/manual/build_hacking.xml branches/gcc-4_7-branch/libstdc++-v3/include/Makefile.in branches/gcc-4_7-branch/libstdc++-v3/libsupc++/Makefile.am branches/gcc-4_7-branch/libstdc++-v3/libsupc++/Makefile.in branches/gcc-4_7-branch/libstdc++-v3/po/Makefile.in branches/gcc-4_7-branch/libstdc++-v3/python/Makefile.in branches/gcc-4_7-branch/libstdc++-v3/src/Makefile.am branches/gcc-4_7-branch/libstdc++-v3/src/Makefile.in branches/gcc-4_7-branch/libstdc++-v3/src/c++11/Makefile.am branches/gcc-4_7-branch/libstdc++-v3/src/c++11/Makefile.in branches/gcc-4_7-branch/libstdc++-v3/src/c++11/compatibility-atomic-c++0x.cc branches/gcc-4_7-branch/libstdc++-v3/src/c++11/compatibility-c++0x.cc branches/gcc-4_7-branch/libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc branches/gcc-4_7-branch/libstdc++-v3/src/c++98/Makefile.am branches/gcc-4_7-branch/libstdc++-v3/src/c++98/Makefile.in branches/gcc-4_7-branch/libstdc++-v3/src/c++98/compatibility-list-2.cc branches/gcc-4_7-branch/libstdc++-v3/src/c++98/compatibility.cc branches/gcc-4_7-branch/libstdc++-v3/testsuite/Makefile.in
[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811 --- Comment #22 from Benjamin Kosnik bkoz at gcc dot gnu.org 2012-11-05 23:43:32 UTC --- Fixed on trunk and 4.7 branch
[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811 --- Comment #20 from Benjamin Kosnik bkoz at gcc dot gnu.org 2012-09-20 02:10:32 UTC --- Author: bkoz Date: Thu Sep 20 02:10:22 2012 New Revision: 191509 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191509 Log: 2012-09-18 Benjamin Kosnik b...@redhat.com PR libstdc++/28811 PR libstdc++/54482 * configure.ac (glibcxx_lt_pic_flag, glibcxx_compiler_pic_flag, glibcxx_compiler_shared_flag): New. Use them. (lt_prog_compiler_pic_CXX): Set via glibcxx_*_flag(s) above. (pic_mode): Set to default. (PIC_CXXFLAGS): Remove. * Makefile.am (PICFLAG, PICFLAG_FOR_TARGET): Remove. Comment. * libsupc++/Makefile.am: Use glibcxx_ld_pic_flag and glibcxx_compiler_shared_flag. Comment. * src/c++11/Makefile.am: Same. * src/c++98/Makefile.am: Same. * src/Makefile.am: Use glibcxx_compiler_pic_flag. * Makefile.in: Regenerated. * aclocal.m4: Same. * configure: Same. * doc/Makefile.in: Same. * include/Makefile.in: Same. * libsupc++/Makefile.in: Same. * po/Makefile.in: Same. * python/Makefile.in: Same. * src/Makefile.in: Same. * src/c++11/Makefile.in: Same. * src/c++98/Makefile.in: Same. * testsuite/Makefile.in: Same. * src/c++11/compatibility-atomic-c++0x.cc: Use _GLIBCXX_SHARED instead of PIC to designate shared-only code blocks. * src/c++11/compatibility-c++0x.cc: Same. * src/c++11/compatibility-thread-c++0x.cc: Same. * src/c++98/compatibility-list-2.cc: Same. * src/c++98/compatibility.cc: : Same. * testsuite/17_intro/shared_with_static_deps.cc: New. * doc/xml/manual/build_hacking.xml: Separate configure from make/build issues, add build details. Added: trunk/libstdc++-v3/testsuite/17_intro/shared_with_static_deps.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/Makefile.am trunk/libstdc++-v3/Makefile.in trunk/libstdc++-v3/aclocal.m4 trunk/libstdc++-v3/configure trunk/libstdc++-v3/configure.ac trunk/libstdc++-v3/doc/Makefile.in trunk/libstdc++-v3/doc/xml/manual/build_hacking.xml trunk/libstdc++-v3/include/Makefile.in trunk/libstdc++-v3/libsupc++/Makefile.am trunk/libstdc++-v3/libsupc++/Makefile.in trunk/libstdc++-v3/po/Makefile.in trunk/libstdc++-v3/python/Makefile.in trunk/libstdc++-v3/src/Makefile.am trunk/libstdc++-v3/src/Makefile.in trunk/libstdc++-v3/src/c++11/Makefile.am trunk/libstdc++-v3/src/c++11/Makefile.in trunk/libstdc++-v3/src/c++11/compatibility-atomic-c++0x.cc trunk/libstdc++-v3/src/c++11/compatibility-c++0x.cc trunk/libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc trunk/libstdc++-v3/src/c++98/Makefile.am trunk/libstdc++-v3/src/c++98/Makefile.in trunk/libstdc++-v3/src/c++98/compatibility-list-2.cc trunk/libstdc++-v3/src/c++98/compatibility.cc trunk/libstdc++-v3/testsuite/Makefile.in
[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811 --- Comment #18 from __vic d.v.a at ngs dot ru 2012-06-27 10:19:18 UTC --- GCC 4.7.1 still fails to link .so against static libstdc++.a in 64-bit mode: $ g++ -shared -fPIC -static-libgcc -static-libstdc++ -o 1.so 1.cpp /usr/bin/ld: /opt/gcc-4.6.1/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/../../../../lib64/libstdc++.a(globals_io.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /opt/gcc-4.6.1/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/../../../../lib64/libstdc++.a: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [1.so] Error 1 32-bit mode is working: $ g++ -m32 -shared -fPIC -static-libgcc -static-libstdc++ -o 1.so 1.cpp
[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811 --- Comment #19 from __vic d.v.a at ngs dot ru 2012-06-27 10:27:14 UTC --- I'm sorry, compiler version was 4.6.1 in previous example. Output for 4.7.1: $ g++ -shared -fPIC -static-libgcc -static-libstdc++ -o 1.so 1.cpp /usr/bin/ld: /opt/gcc-4.7.1/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../lib64/libstdc++.a(compatibility.o): relocation R_X86_64_32 against `_ZTIN10__cxxabiv115__forced_unwindE' can not be used when making a shared object; recompile with -fPIC /opt/gcc-4.7.1/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../lib64/libstdc++.a: could not read symbols: Bad value collect2: error: ld returned 1 exit status
[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.3.6 |---
[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++
--- Comment #17 from rguenth at gcc dot gnu dot org 2010-05-22 18:11 --- GCC 4.3.5 is being released, adjusting target milestone. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.3.5 |4.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811
[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++
--- Comment #16 from rguenth at gcc dot gnu dot org 2009-08-04 12:27 --- GCC 4.3.4 is being released, adjusting target milestone. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.3.4 |4.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811
[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++
--- Comment #14 from bkoz at gcc dot gnu dot org 2009-01-28 01:41 --- Mine. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-08-27 04:55:05 |2009-01-28 01:41:13 date|| Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811
[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++
--- 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
[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++
--- Comment #13 from pluto at agmk dot net 2008-11-14 00:32 --- (In reply to comment #10) If no and --with-pic builds everything twice and it is possible to compile the *.o's intended for libstdc++.so with -DSHARED, i thought about something like this: $ cat makefile SRCS := test.cpp all: libtest.so libtest.a libtest.so: $(SRCS:.cpp=.os) g++ -shared -o $@ $ libtest.a: $(SRCS:.cpp=.o) ar cr $@ $ %.os: %.cpp g++ -c -fpic -DSHARED -o $@ $ %.o: %.cpp g++ -c -fpic -o $@ $ but i can't transform it into autotools templates :/ i saw that elfutils does such trick within src/makefile.am. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811
[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++
--- Comment #12 from hjl dot tools at gmail dot com 2008-06-08 15:45 --- (In reply to comment #8) HJ, are you willing to prepare and test a patch? Many thanks in advance. Sorry, I may not have time for it in the near future. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811
[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++
--- Comment #10 from jakub at gcc dot gnu dot org 2008-06-06 12:14 --- Doesn't --with-pic build just one set of *.o files? If yes, then you are out of luck, either configure libstdc++ without symbol versioning, or you need to use a version script when linking --with-pic libstdc++.a statically. If no and --with-pic builds everything twice and it is possible to compile the *.o's intended for libstdc++.so with -DSHARED, then surely replacing uses of #ifdef PIC with #ifdef SHARED is the way to go. Or leave compatibility.o from libstdc++.a (not sure if it is easily doable with libtool). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811
[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++
--- Comment #7 from cnstar9988 at gmail dot com 2007-09-07 05:58 --- gcc 4.2.1 have the bug too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811
[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++
--- Comment #6 from pluto at agmk dot net 2006-09-08 12:48 --- any idea how to fix this? i can test proposals. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811
[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-08-27 04:55 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-08-27 04:55:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811
