2

I've installed clang++-5.0 to try out new C++17 features, but to get the full experience I need a new library. After being unable to find newer libstdc++, I decided to try out libc++.

I've checked it out using similar way described here.

After checkout, I've compiled it with clang itself, since it was advised to use clang. Compilation went without problems. Then I installed it, make put them in the /usr/local/include/c++/v1 directory.

When I tried to compile anything, I was getting an error saying the compiler couldn't find <stddef.h>. I solved the problem with "redirecting" the includes: -isystem /usr/local/include/c++/v1.

But then linker throws a lot of errors related to exceptions and virtual tables. I have no idea what to do in this case.

Is it possible to fix it?

My setup: ubuntu 16.04 LTS with all updates, clang++-5.0, cmake-3.6 .

Here are my flags:

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -v -stdlib=libc++ -Wall -Wextra -pedantic-errors -std=c++1z -isystem /usr/local/include/c++/v1")

Excerpt from error messages:

//usr/local/lib/libc++.so: undefined reference to `__cxa_end_catch'
//usr/local/lib/libc++.so: undefined reference to `__cxa_pure_virtual'
//usr/local/lib/libc++.so: undefined reference to `__cxa_rethrow'
//usr/local/lib/libc++.so: undefined reference to `vtable for __cxxabiv1::__si_class_type_info'
//usr/local/lib/libc++.so: undefined reference to `vtable for __cxxabiv1::__class_type_info'
//usr/local/lib/libc++.so: undefined reference to `vtable for __cxxabiv1::__vmi_class_type_info'

UPDATE:

After building libc++abi it successfully passes build step, though now it crashes with error saying

error while loading shared libraries: libc++abi.so.1: cannot open shared object file: No such file or directory

Current flags:

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -isystem /usr/local/include/c++/v1 -stdlib=libc++ -lc++abi -Wall -Wextra -pedantic-errors -std=c++1z")

After having a look, I found that they are absent in /usr/lib/, but are present in /usr/local/lib.

Here is the output of ldd program:

linux-vdso.so.1 => (0x00007ffd1b7da000)

libc++abi.so.1 => /usr/local/lib/libc++abi.so.1 (0x00007f69bd322000)

libc++.so.1 => /usr/local/lib/libc++.so.1 (0x00007f69bcf80000)

libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f69bcc76000)

libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f69bca60000)

libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f69bc697000)

libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f69bc479000)

librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f69bc271000) /lib64/ld-linux-x86-64.so.2 (0x000055e63a9a9000)

Community
  • 1
  • 1
Incomputable
  • 2,188
  • 1
  • 20
  • 40
  • The problem is that `libc++abi.so` isn't being included during linking. Newer libc++ versions the `libc++.so` file should be a linker script containing `INPUT(-lc++abi libc++.so.1)`. Is this what you see? Did you include libc++abi repository when building Clang and libc++? What does `clang++ -### -v -stdlib=libc++ -xc++ /dev/null` output? – EricWF Mar 08 '17 at 21:49
  • Make sure to compile libc++abi and libc++ again within the LLVM tree. It should look something like this: http://libcxx.llvm.org/docs/BuildingLibcxx.html#getting-started – EricWF Mar 09 '17 at 06:09
  • What crashes? Did you install libc++abi in `/usr/local/lib` like you did with libc++? – EricWF Mar 09 '17 at 08:01
  • but it's finding libc++.so in the same directory? What's the output of `ldd `? – EricWF Mar 09 '17 at 08:19
  • 1
    My goal as a libc++ maintainer is to make things work out of the box so that nobody needs to turn to stack overflow. Feel free to write a community post, I'll absolutely review it, but the real goal here is to avoid errors and the need for documentation in the first place. – EricWF Mar 09 '17 at 11:53
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/137661/discussion-between-ericwf-and-incomputable). – EricWF Mar 09 '17 at 12:15

1 Answers1

2

So what lead to problem was actually me leaving the part with libc++abi. Most of the procedure is as specified in the docs, with minor deviation.

The procedure for me was roughly as following:

  • Checkout llvm

  • Checkout libc++ and libc++abi. Remember to checkout both!

  • Configure. I'm not sure if it matters, but I builded it with release configuration, e.g. specified -DCMAKE_BUILD_TYPE=Release. Also, make sure that it will be compiled with clang itself.

  • Install both. They will probably be somewhere around /usr/local/lib/ folder.

  • Let compiler know that you want libc++. The flags are -stdlib=libc++ -lc++abi. If it will complain about missing <stddef.h>, add -isystem path/to/includes/ to the compiler flags, which in my case was -isystem /usr/local/include/c++/v1.

Incomputable
  • 2,188
  • 1
  • 20
  • 40
  • > Let compiler know that you want libc++. The flags are `-stdlib=libc++ -lc++abi`. If it will complain about missing ``, add `-isystem path/to/includes/` to the compiler flags, which in my case was `-isystem /usr/local/include/c++/v1`. The flags are -stdlib=libc++ -lc++abi If you have built clang/libc++/libc++abi correctly none of these flags should be needed except `-stdlib=libc++`. – EricWF Mar 09 '17 at 13:08
  • @EricWF: I can confirm that the `-isystem` flag is necessary when installing a new libc++ that doesn't overwrite the existing system one. I have libc++-dev 3.7.0-1 in `/usr/include` and libc++-dev 3.9 in `/usr/local/include`. clang++ tries to include from `/usr/local/include/c++/v1`, and fails with the missing `stddef.h`. Looking at the SVN checkout of libcxx, there is indeed no `stddef.h` in the include directory. – Steve D Apr 19 '17 at 05:35
  • @SteveD, I checked out the llvm source plus libc++ today, and now it works correctly. No need to pass `-isystem` flag anymore. Try to update, I'll amend my findings if they can be reproduced. – Incomputable Apr 25 '17 at 06:32
  • @Incomputable: I've got it working now, so I'm in no hurry to make any changes :). But if you post your steps, I will go through them to see if they work. Making this easier would be a huge help! – Steve D Apr 27 '17 at 17:37
  • @SteveD, it is the same as above, just the `-isystem` part removed. I didn't install them, so I had to link to the shared library by `-Wl,-rpath,/absolute/path`, as specified in [this answer](http://stackoverflow.com/questions/25160245/clang-linking-with-so). It works out of the box, and made life for my testers much easier. I think that making it easier will probably trade off a lot of flexibility, so it might not be an option. – Incomputable Apr 27 '17 at 17:40