[MacPorts] #34288: clang ports use the old/dated libstdc++ from the host (gcc-4.2 based)

[MacPorts]

#34288: clang ports use the old/dated libstdc++ from the host (gcc-4.2 based)
-----------------------------------------------------------------------+----
  Reporter:  christophe.prudhomme@…                                    |       Owner:  jeremyhu@…           
      Type:  defect                                                    |      Status:  reopened             
  Priority:  Normal                                                    |   Milestone:                       
 Component:  ports                                                     |     Version:  2.0.4                
Resolution:                                                            |    Keywords:                       
      Port:  clang-2.9 clang-3.0 clang-3.1 clang-3.2 libstdc++ libc++  |  
-----------------------------------------------------------------------+----

Comment(by help@…):

 Replying to [comment:10 jeremyhu@…]:
 > Right, I need to talk to some people who know more about the low level
 runtimes to figure out what the right course of action is.  I know for
 certain that it's not possible to have more than one ObjC runtime in a
 single process, but I don't know how the C++ runtimes can or can't co-
 exist.  Most of C++ is implemented in the headers themselves as templates,
 and I am worried that passing objects between the g++ 4.7's libstdc++
 runtime and clang++'s libc++ runtime might be problematic.
 >
 > The correct solution may end up being the removal of the libstdc++
 runtimes from the gcc ports.  In fact, even if we do provide a C++ runtime
 in MacPorts, I'd prefer to have that as a separate port rather than
 separately from each compiler.

 Several libstdc++ do not coexist well inside one process. I get backtraces
 like that when compiling with macports gcc46:

 {{{
 malloc: *** error for object 0x10151e500: pointer being freed was not
 allocated

 #0  0x00007fff8eddf588 in malloc_error_break ()
 #1  0x00007fff8ede0942 in free ()
 #2  0x00007fff90154cf5 in std::basic_stringbuf<char,
 std::char_traits<char>, std::allocator<char> >::overflow ()
 #3  0x00007fff9015898e in std::basic_streambuf<char,
 std::char_traits<char> >::xsputn ()
 #4  0x00000001014a8b45 in std::__ostream_insert<char,
 std::char_traits<char> > ()
 #5  0x00007fff7d9a7b80 in vtable for std::basic_stringbuf<char,
 std::char_traits<char>, std::allocator<char> > ()
 #6  0x00007fff90155c8e in std::basic_ostringstream<char,
 std::char_traits<char>, std::allocator<char> >::basic_ostringstream ()
 #7  0xed851f90058d48fb in ?? ()
 }}}
 0x00007fff addresses are from system /usr/lib/libstdc++.dylib and
 0x00000001 are from gcc's libstdc++. Two things are wrong here - they call
 each others functions and they try to free each others objects/memory
 regions. Basicly it's completely broken behaviour. It's a wonder that
 crashes happen so rarely.
 Since there are system frameworks/libraries that are linked against
 /usr/lib/libstdc++ (and libc++, and libobjc), macports compilers should
 use system libstdc++ too and not include their own version of C++ runtime
 library.
 I have no experience with libc++, so I don't know how it plays with
 libstdc++, but probably there's at least no symbol name conflicts.

-- 
Ticket URL: <https://trac.macports.org/ticket/34288#comment:17>
MacPorts <http://www.macports.org/>
Ports system for Mac OS