Hi,
I modified the buildit file to remove ppc and 386 -arch from my build targets, but made no other change and found that I’m missing a file:
- g++ -dynamiclib -nodefaultlibs -arch x86_64 -current_version 1 -compatibility_version 1 -o libc++.1.dylib algorithm.o bind.o chrono.o condition_variable.o hash.o ios.o iostream.o locale.o memory.o mutex.o new.o random.o stdexcept.o strstream.o system_error.o thread.o utility.o valarray.o -install_name /usr/lib/libc++.dylib -Wl,-reexport_library,/usr/lib/libc++abi.dylib /usr/lib/libSystem.B.dylib
ld: file not found: /usr/lib/libc++abi.dylib
collect2: ld returned 1 exit status
Is libc++abi.dylib part of another project?
My goal is to pitch in on this project when I can.
Dave
What platform? But in general yes, it's part of libstdc++ at the moment. It's the ABI part that the web page was talking about.
You can change it by linking against libstdc++ for now.
-eric
Ah, this is a pretty big current gotcha with libc++. libc++ only implements the C++ standard library, but does not (yet) implement all of the C++ ABI routines specified by the itanium C++ ABI. Internally, we have factored that code out of libstdc++ (this is largely code that lives in "libsup++") into a library currently called libc++abi.dylib.
For purposes of bringup, I think it should be enough to link to libstdc++ instead of libc++abi.
-Chris
What's the harm in putting that source in llvm svn also?
Peter
For the current time, Apple is going to maintain ABI compatibility of some low-level bits between libstdc++ and libc++. This is so that clients can create applications that link to disparate dynamic libraries, some which use libstdc++, some which use libc++, and still be able to function with exceptions being thrown across dylib boundaries and one somebody replacing operator new.
With this in mind, it makes sense for us to separate out the ABI stable bits into a 3rd lib which serves an ABI (but not necessarily an API) to both libstdc++ and libc++. As Chris mentioned, this is essentially gcc's libsup++.
-Howard
Snow Leopard :-). I’ll check into it some more. I just thought perhaps I did something obviously wrong.
Internally, we have factored that code out of libstdc++ (this is
largely code that lives in “libsup++”) into a library currently
called libc++abi.dylib.
What’s the harm in putting that source in llvm svn also?
For the current time, Apple is going to maintain ABI compatibility of some low-level bits between libstdc++ and libc++. This is so that clients can create applications that link to disparate dynamic libraries, some which use libstdc++, some which use libc++, and still be able to function with exceptions being thrown across dylib boundaries and one somebody replacing operator new.
With this in mind, it makes sense for us to separate out the ABI stable bits into a 3rd lib which serves an ABI (but not necessarily an API) to both libstdc++ and libc++. As Chris mentioned, this is essentially gcc’s libsup++.
-Howard
C++ not specifying an ABI has been quite a pain in the past for me as a professional software developer. Different versions of gcc wouldn’t even work. I believe an ABI was specified for Itanium by the CodeSourcery folks, but I don’t know that anyone ever tried to nail this down for AMD64 or IA32.
Dave
I'm not opposed to doing this. We'd probably want to keep it in a separate svn module just to keep the licenses clear and obvious.
-Chris
On a related note - is it documented anywhere exactly what is required from the ABI module? Presumably this includes things like the unwinding library, or is that a separate module again?
David
-- Sent from my Difference Engine
I've been thinking about creating this documentation and haven't done so yet. The precise specification, while largely nailed down, still has 1 or 2 degrees of freedom that haven't been set in concrete.
It does include the unwinding library and follows the Itanium C++ ABI (http://www.codesourcery.com/public/cxx-abi/abi-eh.html).
-Howard
Howard, do you want to just post a tarball of this library somewhere? Until we figure out the integration issues, it might be helpful for people trying to play with libc++.
-Chris
On a related note - is it documented anywhere exactly what is required from the ABI module? Presumably this includes things like the unwinding library, or is that a separate module again?
I've been thinking about creating this documentation and haven't done so yet. The precise specification, while largely nailed down, still has 1 or 2 degrees of freedom that haven't been set in concrete.
This would be very useful. The unwinding library functions are barely documented in the GNU implementation (some functions have documentation that tells you the function exists, but not what it does, some just have the code).
It does include the unwinding library and follows the Itanium C++ ABI (http://www.codesourcery.com/public/cxx-abi/abi-eh.html).
Does libc++ only use the functions described here? As I recall, in libstdc++ these are implemented in terms of some others that are semi-public, which are also used by various bits of the higher-level code.
David
-- Sent from my Cray X1
Actually, Nick has some underlying changes he wants to make to libc++abi in the next couple days. Until this happens it doesn't make a lot of sense to send out. We'll push it out after that goes in.
-Chris