[cfe-dev] unraveling libcxxabi/libcxx

David Fang fang at csl.cornell.edu
Mon Apr 8 18:31:26 PDT 2013

Hi Howard,

I whipped up another Makefile to compile tests to different executables, 
where the resulting commands look like:

/Users/fang/local/src/LLVM-svn/gcc40-cmake-build/bin/clang++ -std=c++0x 
-stdlib=libc++ -O0 -no-integrated-as -I../include -cxx-isystem 
-I/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include unwind_01.cpp 
../lib/libc++abi.1.dylib -L/usr/local/experimental/llvm/lib/libcxx/lib  -o 

Unfortunately, I get a ton of test failures.  Just to pick one 

% env DYLD_LIBRARY_PATH=../lib gdb ./unwind_01
GNU gdb 6.3.50-20050815 (Apple version gdb-696) (Sat Oct 20 18:20:28 GMT 
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you 
welcome to change it and/or distribute copies of it under certain 
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for 
This GDB was configured as "powerpc-apple-darwin"...
warning: --arch option not supported in this gdb.
Reading symbols for shared libraries ..... done

(gdb) run
Starting program: 
tcsh: Word too long.
Reading symbols for shared libraries .++ done
libc++abi.dylib: terminating with uncaught exception of type int

Program received signal SIGABRT, Aborted.
0x90047dac in kill ()
(gdb) where
#0  0x90047dac in kill ()
#1  0x9012d7b4 in abort ()
#2  0x00205a18 in abort_message ()
#3  0x00205ce0 in _ZL25default_terminate_handlerv ()
#4  0x00214738 in std::__terminate ()
#5  0x00215888 in __cxxabiv1::call_terminate ()
#6  0x0021580c in __cxxabiv1::scan_eh_tab ()
#7  0x00214d38 in __gxx_personality_v0 ()
#8  0x9143cbc0 in _Unwind_RaiseException ()
#9  0x00212cd4 in __cxa_throw ()
#10 0x000020c8 in f2 ()
#11 0x0000212c in f1 ()
#12 0x000021cc in main ()

I see how unwind_01.cpp is supposed to work.  Any idea why
"throw 55;" isn't getting caught by catch(int)?

The libunwind I'm using happens to be the one shipped with libgcc_s.10.4.
Not sure what Apple version number that would correspond to.

How can I go about debugging this?


> On OS X, you can:
> export DYLD_LIBRARY_PATH=<path-to-libcxx>/lib
> clang++ -std=c++11 -stdlib=libc++ -nostdinc++ -I<path-to-libcxx>/include -L<path-to-libcxx>/lib test.cpp
> (sub in libc++abi where appropriate).  The DYLD_LIBRARY_PATH symbol can contain multiple paths, using ':' as a separator.
> Howard
> On Apr 3, 2013, at 6:30 PM, David Fang <fang at csl.cornell.edu> wrote:
>> Hi Howard and all,
>> I was able to build libcxxabi and libcxx on powerpc-darwin8.
>> I've documented my experiences here. http://www.csl.cornell.edu/~fang/sw/llvm/#libcxx
>> I might need some explanation for how the test suite is expected to be run.  The 'testit' script in libcxxabi doesn't even refer to the libc++abi.dylib that was built, so there must be some implicit assumptions in this script?
>> I'm hoping there's a way to test the dylib before having to install it.
>> Likewise with libc++.
>> Fang
>>> On Apr 2, 2013, at 8:35 PM, David Fang <fang at csl.cornell.edu> wrote:
>>>> Hi,
>>>> 	I'm currently looking into porting libcxx to an ancient system (powerpc-darwin8), and I noticed that libcxx depends on libcxxabi. However, libcxxabi's sources include headers like <exception> which are expected to be in some C++ library.  Does it (mutually) depend on libcxx? Maybe this was obvious, but I take it libcxxabi needs a c++11 compiler to build, correct?  (This would be fine, as I have stage-1 clang built from gcc-4.0/libstdc++.)  Does one {libcxx,libcxxabi} need to be installed before the other, or should they be built cross-referencing each others include dirs?  In terms of shared-library dependencies, libcxx should link to libcxxabi, right?
>>>> Is there better documentation somewhere that I don't know about?
>>>> All I see are html pages at http://libcxxabi.llvm.org and http://libcxx.llvm.org/.
>>> Contributions to better documentation (and your experiences in doing this) are welcome. :-)
>>> Yes, libcxxabi is the lower-level library.  libcxx should link to libcxxabi.
>>> Yes, currently libcxxabi is using -std=c++0x and probably needs it, though I can't think offhand of a specific need.  If you need to, try changing that to -std=c++03.  If there's any breakage it will almost certainly be compile-time breakage.  So that is a safe experiment.
>>> libcxxabi is designed to be ABI compatible with a gcc-4.2 era libstdc++.  And therefore could almost certainly use a libstdc++-4.2 set of headers if need be to build against (another untested theory).
>>> As libcxxabi is the lower-level library, I would go with installing that first.  But understand you're traversing territory where few have gone before.
>>> Keep us posted, and blogs of your experience which might help future porters are welcome.
>>> Howard
>> --
>> David Fang
>> http://www.csl.cornell.edu/~fang/

David Fang

More information about the cfe-dev mailing list