[Bug middle-end/54806] New: [4.7.2 Regression] Undefined symbols: "___emutls_v.*", ... on *-apple-darwin*

[Bug middle-end/54806] New: [4.7.2 Regression] Undefined symbols: "___emutls_v.*", ... on *-apple-darwin*

[whatmannerofburgeristhis at gmail dot com]

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

             Bug #: 54806
           Summary: [4.7.2 Regression] Undefined symbols: "___emutls_v.*",
                    ... on *-apple-darwin*
    Classification: Unclassified
           Product: gcc
           Version: 4.7.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: whatmannerofburgeristhis@gmail.com
              Host: *-apple-darwin*
            Target: *-apple-darwin*
             Build: *-apple-darwin*


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.

[Bug middle-end/54806] [4.7.2 Regression] Undefined symbols: "___emutls_v.*", ... on *-apple-darwin*

[whatmannerofburgeristhis at gmail dot com]

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

--- Comment #1 from Matt Arsenault <whatmannerofburgeristhis at gmail dot com> 2012-10-04 01:10:34 UTC ---
Created attachment 28351
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28351
packaged_task test case

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on *-apple-darwin*

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |4.7.1
   Target Milestone|---                         |4.7.3
            Summary|[4.7.2 Regression]          |[4.7 Regression] Undefined
                   |Undefined symbols:          |symbols: "___emutls_v.*",
                   |"___emutls_v.*", ... on     |... on *-apple-darwin*
                   |*-apple-darwin*             |
      Known to fail|                            |4.7.2

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on *-apple-darwin*

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-10-04 13:43:48 UTC ---
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?

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on *-apple-darwin*

[whatmannerofburgeristhis at gmail dot com]

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

--- Comment #3 from Matt Arsenault <whatmannerofburgeristhis at gmail dot com> 2012-10-04 17:34:35 UTC ---
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

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on x86_64-apple-darwin12

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|*-apple-darwin*             |x86_64-apple-darwin12
               Host|*-apple-darwin*             |x86_64-apple-darwin12
            Summary|[4.7 Regression] Undefined  |[4.7 Regression] Undefined
                   |symbols: "___emutls_v.*",   |symbols: "___emutls_v.*",
                   |... on *-apple-darwin*      |... on
                   |                            |x86_64-apple-darwin12
              Build|*-apple-darwin*             |x86_64-apple-darwin12

--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-10-04 20:37:34 UTC ---
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?

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on x86_64-apple-darwin12

[whatmannerofburgeristhis at gmail dot com]

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

--- Comment #5 from Matt Arsenault <whatmannerofburgeristhis at gmail dot com> 2012-10-05 05:40:59 UTC ---
(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

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on x86_64-apple-darwin12

[howarth at nitro dot med.uc.edu]

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

Jack Howarth <howarth at nitro dot med.uc.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |howarth at nitro dot
                   |                            |med.uc.edu

--- Comment #6 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-10-05 14:33:13 UTC ---
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.

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on x86_64-apple-darwin12

[howarth at nitro dot med.uc.edu]

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

--- Comment #7 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-10-05 14:58:31 UTC ---
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.

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on x86_64-apple-darwin12

[jeremyhu at macports dot org]

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

Jeremy Huddleston <jeremyhu at macports dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jeremyhu at macports dot
                   |                            |org

--- Comment #8 from Jeremy Huddleston <jeremyhu at macports dot org> 2012-10-05 17:41:16 UTC ---
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.

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on x86_64-apple-darwin12

[jeremyhu at macports dot org]

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

--- Comment #9 from Jeremy Huddleston <jeremyhu at macports dot org> 2012-10-05 17:47:02 UTC ---
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

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on x86_64-apple-darwin12

[howarth at nitro dot med.uc.edu]

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

--- Comment #10 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-10-06 00:47:13 UTC ---
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.

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on x86_64-apple-darwin12

[howarth at nitro dot med.uc.edu]

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

--- Comment #11 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-10-06 00:56:37 UTC ---
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
%

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on x86_64-apple-darwin12

[howarth at nitro dot med.uc.edu]

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

--- Comment #12 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-10-06 01:46:04 UTC ---
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.

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on x86_64-apple-darwin12

[jeremyhu at macports dot org]

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

--- Comment #13 from Jeremy Huddleston Sequoia <jeremyhu at macports dot org> 2012-10-06 06:38:54 UTC ---
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

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on x86_64-apple-darwin12

[howarth at nitro dot med.uc.edu]

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

--- Comment #14 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-10-06 17:00:17 UTC ---
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.

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on x86_64-apple-darwin12

[howarth at nitro dot med.uc.edu]

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

--- Comment #15 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-10-06 17:26:51 UTC ---
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.

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on x86_64-apple-darwin12

[jeremyhu at macports dot org]

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

--- Comment #16 from Jeremy Huddleston Sequoia <jeremyhu at macports dot org> 2012-10-06 17:47:52 UTC ---
(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.

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on x86_64-apple-darwin12

[howarth at nitro dot med.uc.edu]

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

--- Comment #17 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-10-06 19:26:49 UTC ---
(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.

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on x86_64-apple-darwin12

[jeremyhu at macports dot org]

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

--- Comment #18 from Jeremy Huddleston Sequoia <jeremyhu at macports dot org> 2012-10-06 19:53:25 UTC ---
(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.

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on x86_64-apple-darwin12

[howarth at nitro dot med.uc.edu]

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

--- Comment #19 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-10-06 20:56:44 UTC ---
(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.

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on x86_64-apple-darwin12

[howarth at nitro dot med.uc.edu]

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

--- Comment #20 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-10-06 21:06:45 UTC ---
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.

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on x86_64-apple-darwin12

[jeremyhu at macports dot org]

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

--- Comment #21 from Jeremy Huddleston Sequoia <jeremyhu at macports dot org> 2012-10-06 21:14:30 UTC ---
(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.

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on x86_64-apple-darwin12

[jeremyhu at macports dot org]

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

--- Comment #22 from Jeremy Huddleston Sequoia <jeremyhu at macports dot org> 2012-10-06 21:15:02 UTC ---
In any event, this is a MacPorts bug for which I have a fix. This upstream bug
should be closed.

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on x86_64-apple-darwin12

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #23 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-10-07 10:51:16 UTC ---
> In any event, this is a MacPorts bug for which I have a fix. This upstream bug
> should be closed.

Agreed. Closing as invalid.