[cfe-dev] libcxxrt+libc++ build regression
Eric Fiselier
eric at efcs.ca
Sat Oct 18 13:29:23 PDT 2014
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
On Sat, Oct 18, 2014 at 5:39 AM, C Bergström <cbergstrom at pathscale.com>
wrote:
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141018/876289d9/attachment.html>
More information about the cfe-dev
mailing list