[cfe-dev] libcxxrt+libc++ build regression

[Eric Fiselier]

>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=<library> where <library> 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



On Sat, Oct 18, 2014 at 2:41 PM, C Bergström <cbergstrom at pathscale.com>
wrote:

>
>
> On Sun, Oct 19, 2014 at 3:29 AM, Eric Fiselier <eric at efcs.ca> wrote:
>
>> 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.
>>
>>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141018/4b601211/attachment.html>