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

[C Bergström]

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/20141019/df25b4a4/attachment.html>