clang ports use the old/dated libstdc++ from the host (gcc-4.2 based)

[christophe.prudhomme@…]

clang3.1 seems to be compiled with c++03 support and not c++11 support it does not compile boost based code

e.g try to compile the following one line code :

#include <boost/signals2.hpp>

and it fails.

it seems that clang 3.1 is actually using an old (from apple) libstdc++ (4.2) library which is c++03 and not the latest one eg from gcc 4.6 or gcc 4.7.

[jeremyhu@…]

Yes, libstdc++ from the host is being used. This is the case with apple-gcc42 as well, but I see that the gccXX ports use their own libstdc++

I don't like the idea of ports built with gcc46 using /opt/local/lib/gcc46/libstdc++.6.dylib and ports built with gcc47 using /opt/local/lib/gcc47/libstdc++.6.dylib ...

1) The gcc-4.2 libsdtc++ doesn't even support c++-03

2) We should make a port for llvm's ​libc++ and ​libc++ABI for use by clang

3) gccXX and clang-X.X ports should be updated to use these new ports if possible.

4) If newer gccXX ports won't work with libc++, we should make a libstdc++ port

[jeremyhu@…]

Actually, ... I dunno.

I don't really like the idea of having multiple C++ runtimes in the same address space, so I'm not sure I want to go down this road. I need to think about this some more.

I think our choices should be:

• provide a single runtime that all of our compilers use (as opposed to a different dylib for each compiler)
• All of our compilers use the host's C++ runtime

The second is consistent with the ObjC runtime, and it is what clang-X.X and apple-gcc42 do.

Lion provides libc++, so clang-X.X use this newer runtime on Lion.

I'm guessing that you are on SL because that would be consistent with the failure that you reported. '#include <boost/signals2.hpp>' compiles fine for me on Lion.

[jeremyhu@…]

Actually, it even works on SL for me with the GNU libstdc++.

You need to provide more information about your setup, what you're running, and what the output is.

~ $ cat test.cxx 
#include <boost/signals2.hpp>

~ $ /opt/local/bin/clang++-mp-3.1 -c test.cxx -I/opt/local/include -v
clang version 3.0 (tags/RELEASE_30/final)
Target: x86_64-apple-darwin10.8.0
Thread model: posix
 "/opt/local/libexec/llvm-3.0/bin/clang" -cc1 -triple x86_64-apple-macosx10.6.8 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name test.cxx -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 127.2 -v -coverage-file test.o -resource-dir /opt/local/libexec/llvm-3.0/bin/../lib/clang/3.0 -I /opt/local/include -fmodule-cache-path /var/tmp/clang-module-cache -fdeprecated-macro -ferror-limit 19 -fmessage-length 121 -stack-protector 1 -fblocks -fobjc-dispatch-method=mixed -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o test.o -x c++ test.cxx
clang -cc1 version 3.0 based upon llvm 3.0 hosted on x86_64-apple-darwin10.8.0
ignoring nonexistent directory "/usr/local/include"
#include "..." search starts here:
#include <...> search starts here:
 /opt/local/include
 /usr/include/c++/4.2.1
 /usr/include/c++/4.2.1/i686-apple-darwin10/x86_64
 /usr/include/c++/4.2.1/backward
 /usr/include/c++/4.0.0
 /usr/include/c++/4.0.0/i686-apple-darwin8/
 /usr/include/c++/4.0.0/backward
 /opt/local/libexec/llvm-3.0/bin/../lib/clang/3.0/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.

[christophe.prudhomme@…]

It is C++11 code that is failing, to enable that just add --std=c++0x or --std=c++11 and you get

In file included from s.cpp:1:
In file included from /opt/local/include/boost/signals2.hpp:15:
/opt/local/include/boost/signals2/deconstruct.hpp:73:22: error: no member named 'forward' in namespace 'std'
                std::forward<Args>(args)...);
                ~~~~~^
/opt/local/include/boost/signals2/deconstruct.hpp:73:30: error: 'Args' does not refer to a value
                std::forward<Args>(args)...);
                             ^
/opt/local/include/boost/signals2/deconstruct.hpp:67:23: note: declared here
    template<class... Args>
                      ^
/opt/local/include/boost/signals2/deconstruct.hpp:300:27: error: no member named 'forward' in namespace 'std'
        new( pv ) T( std::forward<Args>( args )... );
                     ~~~~~^
/opt/local/include/boost/signals2/deconstruct.hpp:300:35: error: 'Args' does not refer to a value
        new( pv ) T( std::forward<Args>( args )... );
                                  ^
/opt/local/include/boost/signals2/deconstruct.hpp:291:33: note: declared here
    template< class T, class... Args >
                                ^
/opt/local/include/boost/signals2/deconstruct.hpp:481:53: error: no member named 'forward' in namespace 'std'
    return deconstruct_access::deconstruct<T>( std::forward<Args>( args )... );
                                               ~~~~~^
/opt/local/include/boost/signals2/deconstruct.hpp:481:61: error: 'Args' does not refer to a value
    return deconstruct_access::deconstruct<T>( std::forward<Args>( args )... );
                                                            ^
/opt/local/include/boost/signals2/deconstruct.hpp:479:29: note: declared here
template< class T, class... Args > postconstructor_invoker< T > deconstruct( Args && ... args )
                            ^
In file included from s.cpp:1:
In file included from /opt/local/include/boost/signals2.hpp:19:
In file included from /opt/local/include/boost/signals2/signal.hpp:38:
In file included from /opt/local/include/boost/signals2/variadic_signal.hpp:21:
/opt/local/include/boost/signals2/detail/variadic_slot_invoker.hpp:22:10: fatal error: 'tuple' file not found
#include <tuple>

I agree that otherwise it compiles ok

[jeremyhu@…]

You're missing --stdlib

$ /opt/local/bin/clang++-mp-3.0 -I/opt/local/include -c test.cxx --stdlib=libc++ --std=c++0x -v clang version 3.0 (tags/RELEASE_30/final) Target: x86_64-apple-darwin11.4.0 Thread model: posix

"/opt/local/libexec/llvm-3.0/bin/clang" -cc1 -triple x86_64-apple-macosx10.7.4 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name test.cxx -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 127.2 -v -coverage-file test.o -resource-dir /opt/local/libexec/llvm-3.0/bin/../lib/clang/3.0 -I /opt/local/include -fmodule-cache-path /var/folders/kd/lg174pm94bz417bmp5vv57j80000gn/T/clang-module-cache -stdlib=libc++ -std=c++0x -fdeprecated-macro -ferror-limit 19 -fmessage-length 125 -stack-protector 1 -fblocks -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-dispatch-method=mixed -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o test.o -x c++ test.cxx

clang -cc1 version 3.0 based upon llvm 3.0 hosted on x86_64-apple-darwin11.4.0 ignoring nonexistent directory "/opt/local/libexec/llvm-3.0/bin/../lib/c++/v1" ignoring nonexistent directory "/usr/local/include" #include "..." search starts here: #include <...> search starts here:

/opt/local/include /usr/include/c++/v1 /opt/local/libexec/llvm-3.0/bin/../lib/clang/3.0/include /usr/include /System/Library/Frameworks (framework directory) /Library/Frameworks (framework directory)

End of search list.

[stephen@…]

Cc Me!

[stephen@…]

From what I can gather from this bug, unlike gcc 4.6/7, MacPorts clang doesn't carry its own standard libraries. It's using the header files and libraries from the system. It's not an issue with OS X 10.7 since it comes with compatible headers and libraries. But on 10.6 there's no system libc++ and its accompanying headers.

For non-C++11 code, it's OK since clang just use the GCC ones. But once -std=c++0x and -stdlib=libc++ are enabled, it will fail compiling any files.

Similar issue occurs when trying to build project deployable to 10.6 on 10.7.

[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.

[suv-sf@…]

Cc Me!

[jeremyhu@…]

Ok, it looks like the only way we can really do this is if we only support C++11 on Lion+. SL and earlier will just use the host libstdc++.

[stephen@…]

It is possible to build libc++ on 10.6. How about creating a port for libc++ that installs into MacPorts path? Clang port has to change to look for the libs in that case though.

[jeremyhu@…]

No.

[michael.lehn@…]

Cc Me!

[help@…]

Replying to 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.

[help@…]

Cc Me!

[jeremyhu@…]

Replying to help@…:

Replying to 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:

The libstdc++ issue is #35770

[josephwinston@…]

Cc Me!

[jeremyhu@…]

r97607 for clang-3.2 ... changes to other versions coming later...

[jeremyhu@…]

r97620 for 3.0 and 3.1

[jeremyhu@…]

2.9 won't support this.

[stephen@…]

Can some please explain what the new changes are? I see that installing clang >= 3.0 now also installs headers from libc++ in /opt/local/libexec/llvm-3.1/lib/c++/v1 and that's where mp-clang will be looking for standard library headers. But as far as I can tell, it doesn't have a matching libc++.dylib and still links against the system one in /usr/lib.

Is this intended and safe? The 2 sets of v1 headers are not the same. Can the difference cause any runtime issue?

Also I am trying this in OS X 10.7 which is shipped with libc++. What happens in 10.6? Does MacPorts installs a copy of libc++ (and the ABI lib) with clang?

Thanks.

[jeremyhu@…]

Replying to stephen@…:

Can some please explain what the new changes are? I see that installing clang >= 3.0 now also installs headers from libc++ in /opt/local/libexec/llvm-3.1/lib/c++/v1 and that's where mp-clang will be looking for standard library headers. But as far as I can tell, it doesn't have a matching libc++.dylib and still links against the system one in /usr/lib.

Yes.

Is this intended and safe? The 2 sets of v1 headers are not the same. Can the difference cause any runtime issue?

I've been told by our internal developers of the C++ runtime that this is the correct way to do it. Using multiple versions of the runtime *will* cause runtime issues as seen in #35770 which is why I never introduced the runtimes and will be removing them from the gcc ports.

Also I am trying this in OS X 10.7 which is shipped with libc++. What happens in 10.6? Does MacPorts installs a copy of libc++ (and the ABI lib) with clang?

Nope. If you want to use libc++ on Snow Leopard, you will need to install it yourself as detailed on ​http://libcxx.llvm.org

Doing it this way will ensure that anything you build on SL will be compatible with Lion.

[stephen@…]

Then I am not quite sure why this fix is needed. Before this fix, when using -stdlib=libc++ on 10.7, clang automatically uses headers in /usr/include/c++/v1 and links against /usr/lib/libc++.dylib. And when using the same option on 10.6, one need to build and install libc++ from source which includes both the headers and the dylib.

Or is this only for when -stdlib=libc++ is NOT used?

[jeremyhu@…]

This fix is needed because /usr/include/c++/v1 is no longer present. I'm not sure where yours are from, but XCode should be installing the headers into /usr/lib/c++/v1 NOT /usr/include/c++/v1, and that's only if you happen to install the CLTools.

[stephen@…]

Oh. My bad! I forgot that when I first ran into this issue, I just symlinked the one in /usr/lib to /usr/include to get around this.

I am so sorry for making so much noise. :)

[jeremyhu@…]

Ok, Snow Leopard users can now use C++11 with clang++. You will need to:

sudo port -v install libcxx

as of r97832 r97833

Unfortunately due to bootstrapping issues, I can't actually add this as a dependency for clang, and since it's only an issue for Snow Leopard, I'm don't want to jump through tons of bootstrapping hoops and do that dance for such an old OS. Hopefully this should satisfy the demand of the masses.