Trouble building libc++

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Trouble building libc++

David Leimbach
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

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Trouble building libc++

Eric Christopher-2

On May 11, 2010, at 6:56 PM, David Leimbach wrote:

> 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?  

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


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Trouble building libc++

Chris Lattner
In reply to this post by David Leimbach
On May 11, 2010, at 6:56 PM, David Leimbach wrote:
> 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?  

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
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Trouble building libc++

Peter O'Gorman
On 05/11/2010 08:59 PM, Chris Lattner wrote:
> 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?

Peter
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Trouble building libc++

Howard Hinnant
On May 11, 2010, at 10:11 PM, Peter O'Gorman wrote:

> On 05/11/2010 08:59 PM, Chris Lattner wrote:
>> 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


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Trouble building libc++

David Leimbach
In reply to this post by Eric Christopher-2


On Tue, May 11, 2010 at 6:58 PM, Eric Christopher <[hidden email]> wrote:

On May 11, 2010, at 6:56 PM, David Leimbach wrote:

> 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?

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

Snow Leopard :-).  I'll check into it some more.  I just thought perhaps I did something obviously wrong.



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Trouble building libc++

David Leimbach
In reply to this post by Howard Hinnant


On Tue, May 11, 2010 at 7:34 PM, Howard Hinnant <[hidden email]> wrote:
On May 11, 2010, at 10:11 PM, Peter O'Gorman wrote:

> On 05/11/2010 08:59 PM, Chris Lattner wrote:
>> 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
 

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Trouble building libc++

Chris Lattner
In reply to this post by Peter O'Gorman

On May 11, 2010, at 7:11 PM, Peter O'Gorman wrote:

> On 05/11/2010 08:59 PM, Chris Lattner wrote:
>> 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?

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
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Trouble building libc++

David Chisnall-2
On 12 May 2010, at 22:52, Chris Lattner wrote:

> On May 11, 2010, at 7:11 PM, Peter O'Gorman wrote:
>
>> On 05/11/2010 08:59 PM, Chris Lattner wrote:
>>> 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?
>
> 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.

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




_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Trouble building libc++

Howard Hinnant
On May 12, 2010, at 6:09 PM, David Chisnall wrote:

> On 12 May 2010, at 22:52, Chris Lattner wrote:
>
>> On May 11, 2010, at 7:11 PM, Peter O'Gorman wrote:
>>
>>> On 05/11/2010 08:59 PM, Chris Lattner wrote:
>>>> 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?
>>
>> 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.
>
> 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.

It does include the unwinding library and follows the Itanium C++ ABI (http://www.codesourcery.com/public/cxx-abi/abi-eh.html).

-Howard


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Trouble building libc++

Chris Lattner

On May 12, 2010, at 3:16 PM, Howard Hinnant wrote:

>>
>> 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.
>
> It does include the unwinding library and follows the Itanium C++ ABI (http://www.codesourcery.com/public/cxx-abi/abi-eh.html).

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
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Trouble building libc++

David Chisnall-2
In reply to this post by Howard Hinnant
On 12 May 2010, at 23:16, Howard Hinnant wrote:

> On May 12, 2010, at 6:09 PM, David Chisnall wrote:
>
>> 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


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Trouble building libc++

Chris Lattner
In reply to this post by Chris Lattner

On May 12, 2010, at 3:26 PM, Chris Lattner wrote:

>
> On May 12, 2010, at 3:16 PM, Howard Hinnant wrote:
>
>>>
>>> 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.
>>
>> It does include the unwinding library and follows the Itanium C++ ABI (http://www.codesourcery.com/public/cxx-abi/abi-eh.html).
>
> 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++.

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
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev