[cfe-dev] libc++abi on linux

[Ben Pope]

On Monday, July 09, 2012 11:10 AM, "C. Bergström" wrote:
> On 07/ 9/12 10:00 AM, Ben Pope wrote:
> <snip>
>> clang++ -std=c++11 -stdlib=libc++ -stdlibabi=libc++abi -stdlibunwind?=???
>>
>> Really that line starts to get a bit scary
 >
> That scary line is not a problem limited to clang, but really any
> compiler which has multiple STL/runtimes that it may work with.  The
> "problem" is that these really should be build time options that define
> a default for the compiler and avoiding having to manually specify them
> at all.  (IMHO and others may disagree)

Yeah, understood.  That's what I was wondering with my final question, 
but I never recall seeing the options, although it's possible they are 
not documented.

>>  that the missing bits (abi/unwind) can be made to Just Work(tm).
>
> For our project outside of clang/llvm we made a top level wrapper build
> system that forces everything to be built at once.  I would say this is
> more of a packager and potentially end user convenience than a
> developer/development requirement.  (Since building standalone
> components is usually easier/faster than a whole suite of things bundled
> together)

Yeah, that's fair enough, I think those types of problems are outside of 
the scope of what I'd like to see done to get this to work.

> I don't know when "we" (PathScale) will have time, but I think we should
> modify our wrapper[1] to be more llvm/clang friendly and solve this damn
> problem once and for all.
>
> (Keep in mind that the approach I'm talking about may have "downsides" -
> such as making the default system C++ compiler and the clang++ not
> compatible -  afaik this would mostly be limited to libc++ issues, but I
> digress)

Yes, the ABI issue is course another "problem".  I'm not sure I'm too 
fussed about the libc++ problem, since it uses a versioned namespace the 
link time errors are pretty obvious, and I don't think it's too much of 
a burden to build components that use STL in their interface to be built 
with the same library!  Inevitably there has to be some breakage for 
progress to occur, this is not a new problem; it's just that gcc has had 
a very stable ABI for quite some time, so in some regards it's been 
forgotten.

> [1] https://github.com/pathscale/path64-suite - I think you could just
> kick out our compiler and put clang/llvm in there as a sub project w/o
> too much issue

I'll take a look, thanks.



For anybody else reading, is there a specific intended direction with 
regard to libc++ on linux?

I guess at a minimum it would be nice if we could say for clang/libc++ 
on linux:

* Forget libc++abi (which would be a shame)
* Use the pathscale components
* Set your clang defaults using method A
* Rejoice.

I wouldn't even mind if I had two build separately two versions of 
clang; one that works with libc++ (with any abi stuff that works) and 
one that works with libstdc++ (which I'd probably not use).

Ben