Re: Default rpaths in BUILD_LDFLAGS

[Khem Raj <raj.khem@gmail.com>]

On 17-03-07 16:43:47, Martin Kelly wrote:
> Hi,
> 
> While debugging an issue with a package that uses llvm-config to compile
> with clang, I started hitting [rpaths] QA warnings because some output
> executables contained absolute rpaths pointing into my build directory.
> After tracing through the issue, I determined the rpaths to eventually be
> originating from the setting of BUILD_LDFLAGS in meta/conf/bitbake.conf. The
> rpath part of this was added in commit 35759f97 to the poky repo.

thats for native packages alone.

> 
> A quick grep through the poky repo reveals that many projects have turned
> off rpath in their builds (the mechanism through which is
> build-system-dependent and doesn't always work right). Obviously, I can do
> the same for clang/llvm-config, but it doesn't seem like the ideal solution
> if many projects are having to do the same.
> 
> I'm wondering if those with more background on this issue could provide more
> detail regarding why rpaths are set at the top level and why they are
> necessary. In addition, I'm wondering if there might be a cleaner way to
> remove the rpaths for those projects that need to do so without each project
> manually writing sed and similar invocations to do it.
> 
> Thanks,
> Martin
> 
> In case you're curious about the background of the issue, my project is
> using the output of llvm-config --ldflags to set its linker flags.
> llvm-config is populating the output --ldflags with whatever it is given for
> CXX_LINK_FLAGS. CXX_LINK_FLAGS is being populated by the generic cmake logic
> in cmake.bbclass, which is getting its flags from BUILD_LDFLAGS in
> meta/conf/bitbake.conf.

I think we shoud not need rpaths for target recipes. We should see if we
can just remove it atleast for /lib /usr/lib