libc++abi on linux

Clang Frontend
#1

Hi All,
    I tried to compile libc++abi using clang and it reported:

src/cxa_exception.hpp:66:9: error: unknown type name '_Unwind_Exception'

    This is defined in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5/include/unwind.h. I found previous posts online that suggested including /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5/include in the include path so that compilation will pick up unwind.h. But I'm trying to be completely free of gcc, so using file will not help.

    I am reading up on libunwind (X11 license, so maybe ok for me). Is there any other alternative?

tia,
asohok

#2

libcxxrt + libunwind is the way to go imho
https://github.com/pathscale/libcxxrt
https://github.com/pathscale/libunwind

These have been tested to work with clang - Admittedly the build process may not be straight forward, but if enough interest maybe we solve that

#3

Thanks for the pointers. I chose libc++abi since it is developed LLVM/Clang community and due to the complexity of the build process for libcxxrt. What does the rest of LLVM/clang community use?

And is http://www.nongnu.org/libunwind/ different from the one you mentioned?

thanks

#4

Hi All,
     I tried to compile libc++abi using clang and it reported:

src/cxa_exception.hpp:66:9: error: unknown type name '_Unwind_Exception'

     This is defined in
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5/include/unwind.h. I
found previous posts online that suggested including
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5/include in the
include path so that compilation will pick up unwind.h. But I'm trying
to be completely free of gcc, so using file will not help.

     I am reading up on libunwind (X11 license, so maybe ok for me). Is
there any other alternative?

libcxxrt + libunwind is the way to go imho
https://github.com/pathscale/libcxxrt
https://github.com/pathscale/libunwind

These have been tested to work with clang - Admittedly the build process
may not be straight forward, but if enough interest maybe we solve that

Thanks for the pointers. I chose libc++abi since it is developed LLVM/Clang community and due to the complexity of the build process for libcxxrt. What does the rest of LLVM/clang community use?

libcxxrt is significantly smaller, used in production, supported and tested by people inside/outside the LLVM community. The build complexity is a result of the kind of errors you're getting. The two projects I listed are explicitly tested to work together and if in the future we create a simple build process that's what will be used.

(Fencepost comment: I've seen hack Makefiles that make it easier to build libcxxrt, but I don't recommend it since it's just a hack and doesn't solve the whole problem (eg building a complete compiler, runtime, STL, unwind. .etc)

And is http://www.nongnu.org/libunwind/ different from the one you mentioned?

Ours has more testing and OS portability - We're missing some ARM related changes that were pushed upstream, but that will probably get pulled in the next 1-2 months.

#5

It would be nice to have a documented/tested/working way of compiling *and linking* programs using libc++/clang/llvm on linux, it seems that libc++abi is pretty close to getting that working.

This comes up on the list every couple of months and libcxxrt/libunwind are usually suggested over libc++abi.

What is the problem? Is there some disagreement about the scope of libc++abi? Is there some specific part that has been excluded that is required on linux but not darwin? Does libc++abi replace libsupcxx (not entirely)? Does libunwind address just the missing bit or is there overlap? If there is overlap is linking order enough to fix that? is libc++abi equivalent to libcxxrt? And there are lots of other questions that come up and it just makes it hard to get going.

I think it's a real shame that this is not documented for linux, I suspect it is preventing the uptake of libc++ with clang on linux and that's a real shame, especially as libc++ has become the default in the next xcode.

There are other problems as well; sometimes it's really a pain to get configure to work properly when trying to choose between which abi bits we want, it would be nice if we could do:

clang++ -std=c++11 -stdlib=libc++ -stdlibabi=libc++abi -stdlibunwind?=???

Really that line starts to get a bit scary, if I'm using clang in c++11 mode, there should be a default that works, I strongly suggest that the default library is libc++ (because stdlibc++ practically always requires a patch to work with clang), and that the missing bits (abi/unwind) can be made to Just Work(tm).

Can the defaults be configured when you configure clang or through some other global means so that I don't have to teach every build system what is required?

Ben

#6

libcxxrt + libunwind is the way to go imho
https://github.com/pathscale/libcxxrt
https://github.com/pathscale/libunwind

These have been tested to work with clang - Admittedly the build process
may not be straight forward, but if enough interest maybe we solve that

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

  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)

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)

./C

[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

#7

<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

#8

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

Would there be a recommendation on the different pieces (specifically ABI and the unwind libraries)?

* 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).

I actually have 3 builds: clang built with g++, clang build with clang, clang build with clang/libc++. Now I'm trying to remove the ABI and unwind dependency on GCC.

thanks
ashok

#9

&quot;C. Bergström&quot;-3 wrote

libcxxrt + libunwind is the way to go imho
https://github.com/pathscale/libcxxrt
https://github.com/pathscale/libunwind

These have been tested to work with clang - Admittedly the build process
may not be straight forward, but if enough interest maybe we solve that

Does this mean that if I want to build libcxxabi with clang++ or other
compiler on linux, I must build libcxxrt and libunwind first? I have tried
simply copying a file unwind.h from ${libunwind-path}/include to
${libcxxabi-path}/include, and it can compile success. But I'm not sure
whether that works right.

#10

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

Would there be a recommendation on the different pieces (specifically
ABI and the unwind libraries)?

This is the crux of my question, really. Since libc++abi has all the boxes ticked for linux: http://libcxxabi.llvm.org/spec.html it's easy to assume that there are no more pieces to the puzzle. I'm sure Howard didn't do the work just for the challenge itself.

Even the libc++ page doesn't really tell you that it isn't complete; this page: http://libcxx.llvm.org gives a hint that libc++abi is needed, at least on Mac. Having said that, it doesn't tell you how to use it on Linux, is there really such little interest?

It's frustrating, because I have managed to get it to work for a small-ish project with quite a few dependencies (but subsequently broken it), but I'm not sure if what I did to get it to work is likely to continue to work with newer versions.

If I use clang with c++11, I either have to use an outdated libstdc++, which reduces my ability to use c++11, or find the right patch for a more recent libstdc++. I just want to use libc++ on Linux, out of the box (or at least, with some instructions that can be found on the website).

What is needed?
* ABI/Unwind recommendation (don't care what)
* Update the instructions on the libc++ home page
* Testing infrastructure?
   * Do automatic test results get uploaded somewhere?
   * If so, where are they?
   * If not, why not?
   * How can I contribute test runs?

Is this what I want? http://lab.llvm.org:8011/one_line_per_build

Is it possible to know what the configuration of the machines are? (Is it libstdc++ for gcc 4.2, libc++, which abi/unwind etc.)

* 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).

I actually have 3 builds: clang built with g++, clang build with clang,
clang build with clang/libc++. Now I'm trying to remove the ABI and
unwind dependency on GCC.

I'm not concerned with how clang is built, I'm concerned about the code that it produces and the dependencies that code has.

For me, the point of having multiple builds was to be able to build-in the arguments for getting the compiler to compile and link my code with a given set of dependencies without having to specify those dependencies each time. I've seen too many broken makefiles for libraries I depend upon that ignore my best efforts to convince them to specify the right arguments to my compiler at the right time.

Basically I want to build a cross-compiler that targets the host, so that I don't have to specify anything to the build system other than the compiler path. It really should be that simple.

Ben

#11

Would there be a recommendation on the different pieces (specifically
ABI and the unwind libraries)?

This is the crux of my question, really. Since libc++abi has all the
boxes ticked for linux: http://libcxxabi.llvm.org/spec.html it's easy to
assume that there are no more pieces to the puzzle. I'm sure Howard
didn't do the work just for the challenge itself.

That was another reason for choosing libc++abi, it wasnt lacking anything in terms of features.

<snip>

It's frustrating, because I have managed to get it to work for a
small-ish project with quite a few dependencies (but subsequently broken
it), but I'm not sure if what I did to get it to work is likely to
continue to work with newer versions.

I can post my steps to build clang with g++ and libc++ and use it to compile other code. As I said earlier, compiling my code with clang/libc++ uses libstdc++ for ABI and unwind pieces (which I'm trying to remove). Even though your goal is different form mine, having a self-contained set of instructions to compile and use clang/libc++ will be helpful in general.

ashok

#12

I believe that should be fine; all unwind.h implementations should be essentially equivalent. The problem which libc++abi + Clang faces seems to be that the unwind.h provided by Clang is simply missing a bunch of the declarations that libc++abi expects it to contain. It tries to #include_next some other unwind.h to solve that problem, but that doesn’t work so well if there’s no system unwind.h and libunwind isn’t installed. I don’t know if there’s a good reason why Clang’s header is missing things which libc++abi uses, like _Unwind_Exception.

#13

Would there be a recommendation on the different pieces (specifically
ABI and the unwind libraries)?

This is the crux of my question, really. Since libc++abi has all the
boxes ticked for linux: http://libcxxabi.llvm.org/spec.html it's easy to
assume that there are no more pieces to the puzzle. I'm sure Howard
didn't do the work just for the challenge itself.

That was another reason for choosing libc++abi, it wasnt lacking
anything in terms of features.

Well, except for the unwind stuff, but that seems intentional, despite there being no documented alternative.

<snip>

It's frustrating, because I have managed to get it to work for a
small-ish project with quite a few dependencies (but subsequently broken
it), but I'm not sure if what I did to get it to work is likely to
continue to work with newer versions.

I can post my steps to build clang with g++ and libc++ and use it to
compile other code.

I'll probably just wait until Chandlers recent build stuff drops, and use CMake. Frankly, I'm happy to have it built with GCC, it's probably faster, anyway. I also found a .deb for Ubuntu (12.04) which appears to work, too, which is fine until I decide I want to move onto master again, but at the moment I'm happy on 3.1.

Due to all of this ABI/Unwind unknownness, I'm just using Clang to compile the code, I'm not that bothered about linking it or distributing it built that way, there just doesn't seem to be enough momentum around getting it to work on Linux right now. It's a real shame.

As I said earlier, compiling my code with
clang/libc++ uses libstdc++ for ABI and unwind pieces (which I'm trying
to remove). Even though your goal is different form mine, having a
self-contained set of instructions to compile and use clang/libc++ will
be helpful in general.

I don't think our goals are much different. I just care less about how Clang is actually built.

Ben

#14

I believe that should be fine; all unwind.h implementations should be
essentially equivalent.

It would be real nice to know if it's been tested against any specific configuration, though.

The problem which libc++abi + Clang faces seems
to be that the unwind.h provided by Clang is simply missing a bunch of
the declarations that libc++abi expects it to contain. It tries to
#include_next some other unwind.h to solve that problem, but that
doesn't work so well if there's no system unwind.h and libunwind isn't
installed.

Yes, it seems strange that these things don't work together.

I don't know if there's a good reason why Clang's header is
missing things which libc++abi uses, like _Unwind_Exception.

Is it because on Darwin, the unwind stuff is part of the platform, but on Linux it seems to be part of gcc?

Ben

#15

clang++ -std=c++11 -stdlib=libc++ -stdlibabi=libc++abi -stdlibunwind?=???

Unlike the STL implementation, the ABI and unwind libraries are per-binary. Generally, the STL implementation will pick one, so you don't need to explicitly specify either unless you are linking the STL implementation itself.

What does the rest of LLVM/clang community use?

In FreeBSD 9.1 (entering beta right about now), we are shipping libstdc++ and libc++, with libstdc++ linked against either libsupc++ or libcxxrt and libc++ linked against libc++. This is a preview release of libc++, so to mix it with libstdc++ in the same executable you need to add a libmap.conf entry telling libstdc++ to pick up libcxxrt instead of libsupc++. In 10.0, we will provide a libstdc++ linked to libcxxrt for legacy compatibility.

All that users need to do is specify -stdlib=libc++. This will be the default on 10.0, and probably be the default when -std=c++11 before then.

David

#16

libcxxrt + libunwind is the way to go imho
https://github.com/pathscale/libcxxrt
https://github.com/pathscale/libunwind

These have been tested to work with clang - Admittedly the build process
may not be straight forward, but if enough interest maybe we solve that

It would be nice to have a documented/tested/working way of compiling
*and linking* programs using libc++/clang/llvm on linux, it seems that
libc++abi is pretty close to getting that working.

This comes up on the list every couple of months and libcxxrt/libunwind
are usually suggested over libc++abi.

Actually, the only people that suggest that are the pathscale folks.

What is the problem? Is there some disagreement about the scope of
libc++abi? Is there some specific part that has been excluded that is
required on linux but not darwin? Does libc++abi replace libsupcxx (not
entirely)? Does libunwind address just the missing bit or is there
overlap? If there is overlap is linking order enough to fix that? is
libc++abi equivalent to libcxxrt? And there are lots of other questions
that come up and it just makes it hard to get going.

The intention is that libc++abi + libc++ is a replacement libstdc++ in its entirety. It is factored the way it is because Apple ships the "STL part" of libstdc++ on top of libc++abi: the ABI library is the common linkage between the two STL implementations. It is a pretty direct replacement for libsupc++, but may not be a 100% analogue (I don't recall).

I think it's a real shame that this is not documented for linux, I
suspect it is preventing the uptake of libc++ with clang on linux and

I completely agree. I really don't care for the distracting pushes towards the pathscale libraries.

-Chris

#17

So could you suggest a replacement for unwind? libc++abi + libc++ still requires unwind.h, and my temporary solution is to pull it from gcc.

thanks,
ashok

#18

You could pull it from libunwind instead. Ultimately, it seems to me that we should fix Clang’s unwind.h to provide all the necessary declarations. Is there any reason not to do so? The current #include_next approach suggests that there might be some Darwin-specific concerns there?

#19

But is that all, just the unwind.h? The libunwind projects (PathScale or nongnu website) provide more files and require compilation etc.

#20

Aha, I forgot about libunwind. I'll see if I can get our sources released.

-Chris