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.
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.
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
