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

[C Bergström]

On Sat, Oct 18, 2014 at 2:22 PM, Eric Fiselier <eric at efcs.ca> wrote:

> > 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 think I see the problem you're trying to solve..

ldd foobar/lib/5.9.0/x8664/64/libc++.so.1

libcxxrt.so => not found
--------
We work-around this by having our compiler driver always add the paths so
the linker can find it later. This may not work for clang though.

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..

Can you see an easy solution?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141018/19f66bc5/attachment.html>