Reopening of #50598 I'm seeing this problem on 4.7.2 when using c++11 packaged_task. The same code worked yesterday with 4.7.1 before I updated.
Created attachment 28351 [details] packaged_task test case
It works for me on powerpc-apple-darwin8, powerpc-apple-darwin9 and x86_64-apple-darwin10 (builds from fink). What is your *-apple-darwin*? and what is your command line?
I'm using it from macports. OS X 10.8.2, x86_64-apple-darwin12.2.0 $ g++ -std=c++11 testcase.cpp Undefined symbols for architecture x86_64: "___emutls_v._ZSt11__once_call", referenced from: void std::call_once<void (std::__future_base::_State_base::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>&, bool&), std::__future_base::_State_base* const, std::reference_wrapper<std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()> >, std::reference_wrapper<bool> >(std::once_flag&, void (std::__future_base::_State_base::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>&, bool&), std::__future_base::_State_base* const&&, std::reference_wrapper<std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()> >&&, std::reference_wrapper<bool>&&) in ccaHSMCA.o "___emutls_v._ZSt15__once_callable", referenced from: void std::call_once<void (std::__future_base::_State_base::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>&, bool&), std::__future_base::_State_base* const, std::reference_wrapper<std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()> >, std::reference_wrapper<bool> >(std::once_flag&, void (std::__future_base::_State_base::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>&, bool&), std::__future_base::_State_base* const&&, std::reference_wrapper<std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()> >&&, std::reference_wrapper<bool>&&) in ccaHSMCA.o void std::__once_call_impl<std::_Bind_simple<std::_Mem_fn<void (std::__future_base::_State_base::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>&, bool&)> (std::__future_base::_State_base*, std::reference_wrapper<std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()> >, std::reference_wrapper<bool>)> >() in ccaHSMCA.o ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status
Jack Howarth has posted his results for 4.8.0 (see http://gcc.gnu.org/ml/gcc-testresults/2012-10/msg00434.html ) without failures for libgomp. What is the origin of your 4.7.2?
(In reply to comment #4) > Jack Howarth has posted his results for 4.8.0 (see > http://gcc.gnu.org/ml/gcc-testresults/2012-10/msg00434.html ) without failures > for libgomp. What is the origin of your 4.7.2? Macports gcc47 package
MacPorts has broken their gcc47 package by adding the patch... https://trac.macports.org/browser/trunk/dports/lang/gcc47/files/no-runtime-stubs.patch which prevents FSF gcc 4.7.2 from linking in all of the additional libgcc symbols from libgcc_ext which is where the ___emutls_v.* symbols reside.
Also note from https://trac.macports.org/ticket/36093 that it appears that MacPorts is playing games with the libstdc++ which FSF gcc uses. This appears to be instigated by https://trac.macports.org/ticket/36092.
I don't know that we're playing "games" with which libstdc++ gcc uses at link time. Instead of having multiple copies of libstdc++ lying around, you now have one, and it's either built from gcc-4.8 (the libstdcxx-devel port) or from gcc-4.7 (the libstdcxx port). It lives as ${prefix}/lib/libstdc++.6.dylib, and is picked up by g++-mp-XX by way of their libstdc++.dylib symlinks. Additionally, we hope to eventually move this libstdc++ on top of libc++abi instead of libsupc++, so it can co-exist with the host libc++ and libstdc++ in the same address space (users seem to do mixing of the C++ runtimes which is what instigated the libstdcxx port to begin with). As for the no-runtime-stubs.patch patch, that is *NOT* used to build gcc47. That is only used in the process of building libstdc++.6.dylib in the libstdcxx port, and it is done in order to intentionally not have the resulting libstdc++.dylib link against the libgcc runtime dynamically. The gcc buildsystem is so convoluted that this seemed to be the easiest way to ensure that the resulting libstdc++.dylib picked up its gcc runtime statically.
The one build config change on MP side that accompanied the version bump was that we now build with --enable-libstdcxx-time for http://trac.macports.org/ticket/36364
I can confirm on 10.7.5 that the provided test case fails with the gcc47-4.7.2 package from current MacPorts but compiles fine with my gcc47-4.7.2 packaging from fink. MacPorts's g++-fsf-4.7 fails the link as... % /opt/local/bin/g++-mp-4.7 -std=c++11 testcase.cpp Undefined symbols for architecture x86_64: "___emutls_v._ZSt11__once_call", referenced from: void std::call_once<void (std::__future_base::_State_base::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>&, bool&), std::__future_base::_State_base* const, std::reference_wrapper<std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()> >, std::reference_wrapper<bool> >(std::once_flag&, void (std::__future_base::_State_base::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>&, bool&), std::__future_base::_State_base* const&&, std::reference_wrapper<std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()> >&&, std::reference_wrapper<bool>&&) in ccj0NKsr.o "___emutls_v._ZSt15__once_callable", referenced from: void std::call_once<void (std::__future_base::_State_base::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>&, bool&), std::__future_base::_State_base* const, std::reference_wrapper<std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()> >, std::reference_wrapper<bool> >(std::once_flag&, void (std::__future_base::_State_base::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>&, bool&), std::__future_base::_State_base* const&&, std::reference_wrapper<std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()> >&&, std::reference_wrapper<bool>&&) in ccj0NKsr.o void std::__once_call_impl<std::_Bind_simple<std::_Mem_fn<void (std::__future_base::_State_base::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>&, bool&)> (std::__future_base::_State_base*, std::reference_wrapper<std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()> >, std::reference_wrapper<bool>)> >() in ccj0NKsr.o ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status [MacBookPro:~/Downloads] howarth% /opt/local/bin/g++-mp-4.7 -std=c++11 testcase.cpp -v Using built-in specs. COLLECT_GCC=/opt/local/bin/g++-mp-4.7 COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin11/4.7.2/lto-wrapper Target: x86_64-apple-darwin11 Configured with: ../gcc-4.7.2/configure --prefix=/opt/local --build=x86_64-apple-darwin11 --enable-languages=c,c++,objc,obj-c++,lto,fortran,java --libdir=/opt/local/lib/gcc47 --includedir=/opt/local/include/gcc47 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-4.7 --with-libiconv-prefix=/opt/local --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-4.7 --with-gxx-include-dir=/opt/local/include/gcc47/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --with-ppl=/opt/local --with-cloog=/opt/local --enable-cloog-backend=isl --disable-cloog-version-check --enable-stage1-checking --disable-multilib --enable-lto --enable-libstdcxx-time --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket --disable-ppl-version-check --with-pkgversion='MacPorts gcc47 4.7.2_2' Thread model: posix gcc version 4.7.2 (MacPorts gcc47 4.7.2_2) COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.7.4' '-std=c++11' '-v' '-shared-libgcc' '-mtune=core2' /opt/local/libexec/gcc/x86_64-apple-darwin11/4.7.2/cc1plus -quiet -v -D__DYNAMIC__ testcase.cpp -fPIC -quiet -dumpbase testcase.cpp -mmacosx-version-min=10.7.4 -mtune=core2 -auxbase testcase -std=c++11 -version -o /var/folders/1l/n78sywl52lz6kkys6nv7mnph0000gp/T//cc6rD9Bc.s GNU C++ (MacPorts gcc47 4.7.2_2) version 4.7.2 (x86_64-apple-darwin11) compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version 3.1.1-p2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/opt/local/lib/gcc47/gcc/x86_64-apple-darwin11/4.7.2/../../../../../x86_64-apple-darwin11/include" #include "..." search starts here: #include <...> search starts here: /opt/local/include/gcc47/c++/ /opt/local/include/gcc47/c++//x86_64-apple-darwin11 /opt/local/include/gcc47/c++//backward /opt/local/lib/gcc47/gcc/x86_64-apple-darwin11/4.7.2/include /opt/local/include /opt/local/lib/gcc47/gcc/x86_64-apple-darwin11/4.7.2/include-fixed /usr/include /System/Library/Frameworks /Library/Frameworks End of search list. GNU C++ (MacPorts gcc47 4.7.2_2) version 4.7.2 (x86_64-apple-darwin11) compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version 3.1.1-p2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 3037b7daaf0a72ee14f224f5c0e272f9 COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.7.4' '-std=c++11' '-v' '-shared-libgcc' '-mtune=core2' /opt/local/bin/as -v -arch x86_64 -force_cpusubtype_ALL -o /var/folders/1l/n78sywl52lz6kkys6nv7mnph0000gp/T//ccAQju5a.o /var/folders/1l/n78sywl52lz6kkys6nv7mnph0000gp/T//cc6rD9Bc.s Apple Inc version cctools-829, GNU assembler version 1.38 COMPILER_PATH=/opt/local/libexec/gcc/x86_64-apple-darwin11/4.7.2/:/opt/local/libexec/gcc/x86_64-apple-darwin11/4.7.2/:/opt/local/libexec/gcc/x86_64-apple-darwin11/:/opt/local/lib/gcc47/gcc/x86_64-apple-darwin11/4.7.2/:/opt/local/lib/gcc47/gcc/x86_64-apple-darwin11/ LIBRARY_PATH=/opt/local/lib/gcc47/gcc/x86_64-apple-darwin11/4.7.2/:/opt/local/lib/gcc47/gcc/x86_64-apple-darwin11/4.7.2/../../../:/usr/lib/ COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.7.4' '-std=c++11' '-v' '-shared-libgcc' '-mtune=core2' /opt/local/libexec/gcc/x86_64-apple-darwin11/4.7.2/collect2 -dynamic -arch x86_64 -macosx_version_min 10.7.4 -weak_reference_mismatches non-weak -o a.out -lcrt1.10.6.o -L/opt/local/lib/gcc47/gcc/x86_64-apple-darwin11/4.7.2 -L/opt/local/lib/gcc47/gcc/x86_64-apple-darwin11/4.7.2/../../.. /var/folders/1l/n78sywl52lz6kkys6nv7mnph0000gp/T//ccAQju5a.o -lstdc++ -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lSystem -v collect2 version 4.7.2 /opt/local/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.7.4 -weak_reference_mismatches non-weak -o a.out -lcrt1.10.6.o -L/opt/local/lib/gcc47/gcc/x86_64-apple-darwin11/4.7.2 -L/opt/local/lib/gcc47/gcc/x86_64-apple-darwin11/4.7.2/../../.. /var/folders/1l/n78sywl52lz6kkys6nv7mnph0000gp/T//ccAQju5a.o -lstdc++ -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lSystem -v @(#)PROGRAM:ld PROJECT:ld64-133.3 configured to support archs: armv6 armv7 i386 x86_64 Library search paths: /opt/local/lib/gcc47/gcc/x86_64-apple-darwin11/4.7.2 /opt/local/lib/gcc47 /usr/lib /usr/local/lib Framework search paths: /Library/Frameworks/ /System/Library/Frameworks/ Undefined symbols for architecture x86_64: "___emutls_v._ZSt11__once_call", referenced from: void std::call_once<void (std::__future_base::_State_base::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>&, bool&), std::__future_base::_State_base* const, std::reference_wrapper<std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()> >, std::reference_wrapper<bool> >(std::once_flag&, void (std::__future_base::_State_base::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>&, bool&), std::__future_base::_State_base* const&&, std::reference_wrapper<std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()> >&&, std::reference_wrapper<bool>&&) in ccAQju5a.o "___emutls_v._ZSt15__once_callable", referenced from: void std::call_once<void (std::__future_base::_State_base::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>&, bool&), std::__future_base::_State_base* const, std::reference_wrapper<std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()> >, std::reference_wrapper<bool> >(std::once_flag&, void (std::__future_base::_State_base::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>&, bool&), std::__future_base::_State_base* const&&, std::reference_wrapper<std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()> >&&, std::reference_wrapper<bool>&&) in ccAQju5a.o void std::__once_call_impl<std::_Bind_simple<std::_Mem_fn<void (std::__future_base::_State_base::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>&, bool&)> (std::__future_base::_State_base*, std::reference_wrapper<std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()> >, std::reference_wrapper<bool>)> >() in ccAQju5a.o ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status whereas g++-fsf-4.7 on fink links properly as... % g++-fsf-4.7 -std=c++11 testcase.cpp -v Using built-in specs. COLLECT_GCC=g++-fsf-4.7 COLLECT_LTO_WRAPPER=/sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin11.4.2/4.7.2/lto-wrapper Target: x86_64-apple-darwin11.4.2 Configured with: ../gcc-4.7.2/configure --prefix=/sw --prefix=/sw/lib/gcc4.7 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.7/info --enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.7 --enable-cloog-backend=isl Thread model: posix gcc version 4.7.2 (GCC) COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.7.4' '-std=c++11' '-v' '-shared-libgcc' '-mtune=core2' /sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin11.4.2/4.7.2/cc1plus -quiet -v -D__DYNAMIC__ testcase.cpp -fPIC -quiet -dumpbase testcase.cpp -mmacosx-version-min=10.7.4 -mtune=core2 -auxbase testcase -std=c++11 -version -o /var/folders/1l/n78sywl52lz6kkys6nv7mnph0000gp/T//ccqbRW1j.s GNU C++ (GCC) version 4.7.2 (x86_64-apple-darwin11.4.2) compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version 3.1.1, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/sw/lib/gcc4.7/lib/gcc/x86_64-apple-darwin11.4.2/4.7.2/../../../../x86_64-apple-darwin11.4.2/include" #include "..." search starts here: #include <...> search starts here: /sw/lib/gcc4.7/lib/gcc/x86_64-apple-darwin11.4.2/4.7.2/../../../../include/c++/4.7.2 /sw/lib/gcc4.7/lib/gcc/x86_64-apple-darwin11.4.2/4.7.2/../../../../include/c++/4.7.2/x86_64-apple-darwin11.4.2 /sw/lib/gcc4.7/lib/gcc/x86_64-apple-darwin11.4.2/4.7.2/../../../../include/c++/4.7.2/backward /sw/lib/gcc4.7/lib/gcc/x86_64-apple-darwin11.4.2/4.7.2/include /sw/lib/gcc4.7/include /sw/lib/gcc4.7/lib/gcc/x86_64-apple-darwin11.4.2/4.7.2/include-fixed /usr/include /System/Library/Frameworks /Library/Frameworks End of search list. GNU C++ (GCC) version 4.7.2 (x86_64-apple-darwin11.4.2) compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version 3.1.1, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: c8f330d0099bd2c4219a56cc67fa3751 COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.7.4' '-std=c++11' '-v' '-shared-libgcc' '-mtune=core2' as -arch x86_64 -force_cpusubtype_ALL -o /var/folders/1l/n78sywl52lz6kkys6nv7mnph0000gp/T//ccIAuiv1.o /var/folders/1l/n78sywl52lz6kkys6nv7mnph0000gp/T//ccqbRW1j.s COMPILER_PATH=/sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin11.4.2/4.7.2/:/sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin11.4.2/4.7.2/:/sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin11.4.2/:/sw/lib/gcc4.7/lib/gcc/x86_64-apple-darwin11.4.2/4.7.2/:/sw/lib/gcc4.7/lib/gcc/x86_64-apple-darwin11.4.2/ LIBRARY_PATH=/sw/lib/gcc4.7/lib/gcc/x86_64-apple-darwin11.4.2/4.7.2/:/sw/lib/gcc4.7/lib/gcc/x86_64-apple-darwin11.4.2/4.7.2/../../../:/usr/lib/ COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.7.4' '-std=c++11' '-v' '-shared-libgcc' '-mtune=core2' /sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin11.4.2/4.7.2/collect2 -dynamic -arch x86_64 -macosx_version_min 10.7.4 -weak_reference_mismatches non-weak -o a.out -lcrt1.10.6.o -L/sw/lib/gcc4.7/lib/gcc/x86_64-apple-darwin11.4.2/4.7.2 -L/sw/lib/gcc4.7/lib/gcc/x86_64-apple-darwin11.4.2/4.7.2/../../.. /var/folders/1l/n78sywl52lz6kkys6nv7mnph0000gp/T//ccIAuiv1.o -lstdc++ -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lSystem -v collect2 version 4.7.2 /usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.7.4 -weak_reference_mismatches non-weak -o a.out -lcrt1.10.6.o -L/sw/lib/gcc4.7/lib/gcc/x86_64-apple-darwin11.4.2/4.7.2 -L/sw/lib/gcc4.7/lib/gcc/x86_64-apple-darwin11.4.2/4.7.2/../../.. /var/folders/1l/n78sywl52lz6kkys6nv7mnph0000gp/T//ccIAuiv1.o -lstdc++ -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lSystem -v @(#)PROGRAM:ld PROJECT:ld64-134.9 configured to support archs: armv6 armv7 armv7s i386 x86_64 Library search paths: /sw/lib/gcc4.7/lib/gcc/x86_64-apple-darwin11.4.2/4.7.2 /sw/lib/gcc4.7/lib /usr/lib /usr/local/lib Framework search paths: /Library/Frameworks/ /System/Library/Frameworks/ % and the resulting a.out runs fine.
Also for gcc47-4.7.2 from fink, I see... % nm /sw/lib/gcc4.7/lib/libstdc++.6.dylib | grep emutls U ___emutls_get_address 00000000000b72c0 D ___emutls_v._ZSt11__once_call 00000000000b72a0 D ___emutls_v._ZSt15__once_callable 00000000000b6e20 d ___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global but for gcc47-4.7.2 from MacPorts, I see... % nm /opt/local/lib/libstdc++.6.dylib | grep emutls %
I would also add, regarding the broken emutls support in libstdc++.6.dylib packaged by MacPorts, that clang for darwin11 provides tls support since Xcode 4.2. FSF gcc only supports emutls because no one written the required changes to emit the necessary tls assembly code for darwin >=11. So the emutls support should be left intact.
I see this issue with older gcc47 versions that predate the bump to 4.7.2 and addition of --enable-libstdcxx-time, specifically: $ g++-mp-4.7 --version g++-mp-4.7 (MacPorts gcc47 4.7.1_7+universal) 4.7.1 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. with libstdcxx-devel @4.8-20120923
Interestingly Macports' libgomp shows the same expected emutls related symbols as fink... % nm libgomp.1.dylib | grep emutls U ___emutls_get_address 000000000000b1e0 d ___emutls_v.gomp_tls_data I suspect the absence of ___emutls_v.* symbols in the MacPorts gcc47's libstdc++.6.dylib could be due to the fact that clang is used to build it rather than a proper full bootstrap. Please try restoring the bootstrap and see if the symbols are restored to libstdc++.6.dylib.
I believe your no-runtime-stubs.patch used during the initial build of libstdc++ is at fault... --- gcc/config/darwin.h.orig 2012-09-13 20:20:33.000000000 -0700 +++ gcc/config/darwin.h 2012-09-13 20:23:03.000000000 -0700 @@ -325,17 +325,8 @@ extern GTY(()) int darwin_ms_struct; #undef REAL_LIBGCC_SPEC #define REAL_LIBGCC_SPEC \ "%{static-libgcc|static: -lgcc_eh -lgcc; \ - shared-libgcc|fexceptions|fgnu-runtime: \ - %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_s.10.4) \ - %:version-compare(>< 10.5 10.6 mmacosx-version-min= -lgcc_s.10.5) \ - %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_ext.10.4) \ - %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_ext.10.5) \ - -lgcc ; \ - :%:version-compare(>< 10.3.9 10.5 mmacosx-version-min= -lgcc_s.10.4) \ - %:version-compare(>< 10.5 10.6 mmacosx-version-min= -lgcc_s.10.5) \ - %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_ext.10.4) \ - %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_ext.10.5) \ - -lgcc }" + shared-libgcc|fexceptions|fgnu-runtime: -lgcc; \ + : -lgcc }" /* We specify crt0.o as -lcrt0.o so that ld will search the library path. --- libgcc/config/t-slibgcc-darwin.orig 2012-09-13 20:26:11.000000000 -0700 +++ libgcc/config/t-slibgcc-darwin 2012-09-13 20:27:08.000000000 -0700 @@ -39,7 +39,7 @@ endif LGCC_FILES = libgcc_s.$(SHLIB_SOVERSION)$(SHLIB_EXT) LGCC_FILES += $(LGCC_STUBS) -LEXT_STUBS = libgcc_ext.10.4$(SHLIB_EXT) libgcc_ext.10.5$(SHLIB_EXT) +LEXT_STUBS = LGCC_FILES += $(LEXT_STUBS) INSTALL_FILES=$(LGCC_FILES) These changes will certainly keep config.h in the libstdc++-v3 build directory from having... #define HAVE_TLS Why is it so critical for MacPorts to eliminate the linkage on libgcc_ext.10.4/ libgcc_ext.10.5? IMHO, the current approach is extremely radical.
(In reply to comment #14) > Interestingly Macports' libgomp shows the same expected emutls related symbols > as fink... > > % nm libgomp.1.dylib | grep emutls > U ___emutls_get_address > 000000000000b1e0 d ___emutls_v.gomp_tls_data > > I suspect the absence of ___emutls_v.* symbols in the MacPorts gcc47's > libstdc++.6.dylib could be due to the fact that clang is used to build it > rather than a proper full bootstrap. Please try restoring the bootstrap and see > if the symbols are restored to libstdc++.6.dylib. We do a full bootstrap first before building libstdc++. There is an issue with clang (fixed in llvm-3.2) which prevents us from using clang to build libstdc++ (In reply to comment #15) > I believe your no-runtime-stubs.patch used during the initial build of > libstdc++ is at fault... > ... > > These changes will certainly keep config.h in the libstdc++-v3 build directory > from having... > > #define HAVE_TLS Why? That seems odd. > Why is it so critical for MacPorts to eliminate the linkage on > libgcc_ext.10.4/ libgcc_ext.10.5? Because it doesn't exist.
(In reply to comment #16) > > These changes will certainly keep config.h in the libstdc++-v3 build directory > > from having... > > > > #define HAVE_TLS > > Why? That seems odd. Not really. The use of the no-runtime-stubs.patch patch would keep the tests in config/tls.m4 for working properly as it breaks the ability of the xgcc compiler from accessing the emutls support calls residing in libgcc_ext.10.4/5. > > > Why is it so critical for MacPorts to eliminate the linkage on > > libgcc_ext.10.4/ libgcc_ext.10.5? > > Because it doesn't exist. This is the wrong approach. You shouldn't be trying to gut libgcc_ext from libstdc++-v3 but rather creating an additional splitoff for libgcc_s/libgcc_ext.10.4/5 so that they are kept at the latest level.
(In reply to comment #17) > (In reply to comment #16) > > > These changes will certainly keep config.h in the libstdc++-v3 build directory > > > from having... > > > > > > #define HAVE_TLS > > > > Why? That seems odd. > > Not really. The use of the no-runtime-stubs.patch patch would keep the tests > in config/tls.m4 for working properly as it breaks the ability of the xgcc > compiler > from accessing the emutls support calls residing in libgcc_ext.10.4/5. Nothing actually "resides in" libgcc_ext.10.[45].dylib ... those are stub libraries which result in those symbols resolving to /opt/local/lib/gccXX/libgcc_s.1.dylib. > > > Why is it so critical for MacPorts to eliminate the linkage on > > > libgcc_ext.10.4/ libgcc_ext.10.5? > > > > Because it doesn't exist. > > This is the wrong approach. You shouldn't be trying to gut libgcc_ext from > libstdc++-v3 but > rather creating an additional splitoff for libgcc_s/libgcc_ext.10.4/5 so that > they are kept at > the latest level. Yes, that was what I eventually want to do, but this was the first step of that approach. Still, this *should* work. Note that the libgcc_ext.10.[45] are not actually needed if we're going to be using the libgcc runtime. This is the whole reason why I suggest just removing them entirely in a future release. The whole point of those stubs is to let let linker pick up some of the runtime from libSystem and the rest (things added after gcc-4.2) from the in-tree libgcc_s.dylib. If we're going to be in the business of shipping our own compiler runtime, we don't need to let some parts resolve to libSystem and others resolve to ours. We should just let it all resolve to ours.
(In reply to comment #18) > Note that the libgcc_ext.10.[45] are not actually needed if we're going to be > using the libgcc runtime. This is the whole reason why I suggest just removing > them entirely in a future release. The whole point of those stubs is to let > let linker pick up some of the runtime from libSystem and the rest (things > added after gcc-4.2) from the in-tree libgcc_s.dylib. If we're going to be in > the business of shipping our own compiler runtime, we don't need to let some > parts resolve to libSystem and others resolve to ours. We should just let it > all resolve to ours. My understanding is that the libgcc symbols that have been subsumed into libSystem as of darwin10 and will always override those provided by any additional libgcc. The following messages from the darwin linker developer on llvm-dev covered this and related issues with the unwinder. http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025894.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025898.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025900.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025908.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025909.html Perhaps you are proposing that eventually we gut the duplicate symbols, now in libSystem, out of FSF libgcc_s but that would have to be done very carefully. Over a years work went into the libgcc_ext design and implementation. A similar effort would be required to gracefully replace it.
Also, you might want to look at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888 which shows the thought process and issues that arose during the libgcc_ext development.
(In reply to comment #19) > (In reply to comment #18) > > Note that the libgcc_ext.10.[45] are not actually needed if we're going to be > > using the libgcc runtime. This is the whole reason why I suggest just removing > > them entirely in a future release. The whole point of those stubs is to let > > let linker pick up some of the runtime from libSystem and the rest (things > > added after gcc-4.2) from the in-tree libgcc_s.dylib. If we're going to be in > > the business of shipping our own compiler runtime, we don't need to let some > > parts resolve to libSystem and others resolve to ours. We should just let it > > all resolve to ours. > > My understanding is that the libgcc symbols that have been subsumed into > libSystem as of > darwin10 and will always override those provided by any additional libgcc. yes > The > following messages > from the darwin linker developer on llvm-dev covered this and related issues > with the unwinder. > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025894.html > http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025898.html > http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025900.html > http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025908.html > http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025909.html > > Perhaps you are proposing that eventually we gut the duplicate symbols, now in > libSystem, out of FSF libgcc_s but that would have to be done very carefully. > Over > a years work went into the libgcc_ext design and implementation. A similar > effort > would be required to gracefully replace it. Yes ... which is why I simply mentioned it in a comment and haven't started going down that road except as a brain exercise.
In any event, this is a MacPorts bug for which I have a fix. This upstream bug should be closed.
> In any event, this is a MacPorts bug for which I have a fix. This upstream bug > should be closed. Agreed. Closing as invalid.