libcxxrt+libc++ build regression

Hi guys

Please don’t break the libcxxrt+libc++ build.

– Looking for __gcc_personality_v0 in gcc_s - not found
CMake Error at cmake/Modules/HandleLibCXXABI.cmake:39 (message):
Failed to find ABI library: cxxrt
Call Stack (most recent call first):
cmake/Modules/HandleLibCXXABI.cmake:110 (setup_abi_lib)
CMakeLists.txt:91 (include)

– Configuring incomplete, errors occurred!

Hello,

Please don’t break the libcxxrt+libc++ build.

I try my hardest not to break any builds :slight_smile:
CMake now uses find_library to locate and properly link libcxxrt. For some reason CMake cannot find your libcxxrt installation.
Could you provide more information about where your copy of libcxxrt is installed?

To manually tell CMake where to look add -DCMAKE_LIBRARY_PATH=path/to/libcxxrt to your CMake configuration.
I’ve just testing libcxxrt + libc++ on linux and everything works on my end.

Please let me know if you have any more problems.

/Eric

I’m curious why you’re using find_library and why it worked fine before.

Abbreviated paths
/somepath/bot/src/libcxx

/somepath/bot/src/libcxxrt

cmake is being ran from
/somepath/bot/build/foobar - In our case we have a global cmake which wraps everything

I'm curious why you're using find_library and why it worked fine before.

It's the standard CMake way of doing things.

Abbreviated paths
/somepath/bot/src/libcxx
/somepath/bot/src/libcxxrt

cmake is being ran from
/somepath/bot/build/foobar - In our case we have a global cmake which
wraps everything

I think we were explicitly setting the path before (I need to double
check this) and if that variable is set - find_path shouldn't be used

This sounds very likely like your hard coded variables no longer match
reality. You may have to update your build bot, but I don't really see how
we can help with a custom CMake setup that others don't have and isn't
represented by one of the public build bots? :: shrug ::

I’m curious why you’re using find_library and why it worked fine before.

The change was made so that the ABI library did not need to be located on the linkers search path.
find_library is used so that CMake properly links against the library.

Abbreviated paths
/somepath/bot/src/libcxx

/somepath/bot/src/libcxxrt

cmake is being ran from
/somepath/bot/build/foobar - In our case we have a global cmake which wraps everything

The important path is where libcxxrt.so is located. Could you provide that?

I think we were explicitly setting the path before (I need to double check this) and if that variable is set - find_path shouldn’t be used

Would you be able to clarify this? What path and what variable are you setting? What about find_path?

/Eric

> I'm curious why you're using find_library and why it worked fine before.

The change was made so that the ABI library did not need to be located on
the linkers search path.
find_library is used so that CMake properly links against the library.

> Abbreviated paths
> /somepath/bot/src/libcxx
> /somepath/bot/src/libcxxrt
>
> cmake is being ran from
> /somepath/bot/build/foobar - In our case we have a global cmake which
wraps everything

The important path is where libcxxrt.so is located. Could you provide that?

/somepath/build/Xcompiler/lib/5.9.0/x8664/64/libcxxrt.so

> I think we were explicitly setting the path before (I need to double
check this) and if that variable is set - find_path shouldn't be used

Would you be able to clarify this? What path and what variable are you
setting? What about find_path?

in the cmake cache here's what I found, but I may not be looking in all the
right places

Top level (doesn't matter)
//Path to libcxx source directory
LLVM_EXTERNAL_LIBCXX_SOURCE_DIR:PATH=/somepath/both/src//libcxx

in libcxx/build-x86_64-shared/CMakeCache.txt I point to the cxxrt
//Paths to C++ ABI header directories separated by ';'.

So it looks like I was wrong - we aren't setting any path for the location
of libcxxrt.so # just the headers..

I looked a bit closer and here’s my best guess what’s happening in my case.

We build both libcxxrt and libc++ at the same time. One is a dependency to the other, but there’s a parent cmake project handling this. The libc++ cmake generated at the same time as libcxxrt and thus why find_library can’t find the “soon-to-be-built” libcxxrt. Previously we let the compiler handle the -L and friends for libcxxrt since it’s special and needs to be relocatable. Personally, I don’t think this is an unreasonable build scenario and I hope there’s an easy way to support it. (Either by disabling find_library under some conditional or something else)

It should be easy to do this, but I can send a patch if it’s more convenient

Thanks

Hi All,

One thing I hope we can avoid is having an rpath always set. (Some guessing about the flags which cmake start adding) A build server path won’t be the same as the end user path and imho it’s not good to have the “wrong” hardcoded path still embedded. This would impact distributors.

Very good point. This change does add the ABI libraries path to libc++‘s rpath. However by default CMake removes the rpath from the library when it is installed.
If you don’t want the rpath while while the library is in the build tree you can configure cmake using `CMAKE_SKIP_BUILD_RPATH=TRUE’. CMake allows for the RPATH handling to by highly customized without having to modify libc++'s CMakeList.txt. Please read http://www.cmake.org/Wiki/CMake_RPATH_handling for further details.

‎What do you think about just not using find_path for cxxrt. If it impacts anyone you can assign the bug to me and I’ll handle it.

I would be uncomfortable with that behavior. You should be able to configure for each ABI library in the same way.

We build both libcxxrt and libc++ at the same time. One is a dependency to the other, but there’s a parent cmake project handling this. The libc++ cmake generated at the same time as libcxxrt and thus why find_library can’t find the “soon-to-be-built” libcxxrt. Previously we let the compiler handle the -L and friends for libcxxrt since it’s special and needs to be relocatable. Personally, I don’t think this is an unreasonable build scenario and I hope there’s an easy way to support it. (Either by disabling find_library under some conditional or something else)

That makes sense. Is the target you use to build libcxxrt named “cxxrt” by chance? I agree it is a reasonable scenario and I think we should be able to support it. However, I’m uncomfortable committing to a supported way to configure CMake that doesn’t work 100%. Currently, with what your asking, there is no way to pass the test suite enough information to find the ABI library. I don’t think it’s unreasonable that libc++'s configuration fails if the library cannot be found.

On your end have you considered handling libc++ using CMake’s ExternalProject functionality?
That seems like a standard CMake way of handling your problem.

/Eric

I agree that typically this would be the correct thing to do. I am
hopefully not asking for a "hack", but bootstrapping compiler internal
libraries is tricky and I'd really like to keep this as tightly coupled as
possible.

What about a variable LIBCXX_CXX_ABI_LIBRARY_PATH - this is similar to
what's being done with LIBCXX_LIBCXXABI_INCLUDE_PATHS

So setup_abi_lib would get another parameter (LIBCXX_CXX_ABI_LIBRARY_PATH)
and if set then find_library wouldn't be used. This would help me a lot and
avoid the whole rpath and external project rabbit hole..

Thanks

What about a variable LIBCXX_CXX_ABI_LIBRARY_PATH - this is similar to what’s being done with LIBCXX_LIBCXXABI_INCLUDE_PATHS

So setup_abi_lib would get another parameter (LIBCXX_CXX_ABI_LIBRARY_PATH) and if set then find_library wouldn’t be used.

I’ll take a look at doing that, since it seems like a reasonable solution. I would really like to use find_library by default since it’s the typical CMake way of doing things.
I also like that it sets the rpath for the ABI library so they are coupled together while testing.

I’m currently looking at the possibility of introducing LIBCXX_CXX_ABI_LIBRARY= where can be either:

  • A full path to the library.so
  • A cmake target
  • A library name (ex. stdc++ for libstdc++).

but this makes it very difficult to tell the testsuite where to find the library.

This would help me a lot and avoid the whole rpath and external project rabbit hole.

I want to inquire more about your concerns about the rpath.
A) Is it not possible to pass CMAKE_SKIP_BUILD_RPATH to just libc++?
B) Why is it important that libc++ has no rpath? (Remebering that the install rule re-links libc++ with an empty rpath).

One last question, It seems possible that the “cxxrt” libc++ was linking against is a CMake target as opposed to a library. Is the name of your CMake target for building libcxxrt called cxxrt?

/Eric