[Buildroot] [autobuild.buildroot.net] Build results for 2018-04-09
Valentin Korenblit
valentin.korenblit at smile.fr
Tue Apr 10 09:02:17 UTC 2018
Hello,
On 10/04/2018 10:41, Thomas Petazzoni wrote:
> Hello,
>
> On Tue, 10 Apr 2018 10:35:34 +0200, Valentin Korenblit wrote:
>
>>> So while this will indeed cause a problem for llvm-config in the SDK
>>> situation, I don't quite understand how you get this $ORIGIN/../lib
>>> today, without running "make sdk".
>> To be more precise, this is the RPATH:
>>
>> (RPATH) Library rpath: [/home/vakor/buildroot/output/host/lib:$ORIGIN/../lib]
>>
>> I haven't run make sdk.
> Meh. Then either I no longer understand how Buildroot works, or it's
> the LLVM build system that adds $ORIGIN/../lib in the RPATH.
It is effectively LLVM that modifies the RPATH in AddLLVM.cmake:
https://pastebin.com/JGWrsLsi
I'll try to patch this file to see if we can get it working.
> But I believe your situation highlights a larger problem: we currently
> use all <foo>-config scripts in STAGING_DIR because that's where
> libraries install them, but that only works because all those programs
> are scripts, and not compiled programs.
Yes, we were discussing this yesterday with Romain, in general they are scripts.
> With compiled programs, it indeed doesn't work well to have host
> binaries in STAGING_DIR, due to the RPATH issues. I'm not sure how to
> solve this. Should we have all those <foo>-config programs in a
> separate location ? But apparently, this llvm-config program behaves
> different depending on its location, so if we move it elsewhere, it
> won't return the right results anymore.
At least for llvm-config, we cannot move it to other place. I don't know
if there are any other packages that deal with the same kind of problem.
>>> One possibility is to do like we do for postgresql: provide our own
>>> minimal -config script. See package/postgresql/pg_config for an example.
>> I'll take a look.
> If the output returned by llvm-config is relatively simple, and it
> doesn't have gazillion of options, then it is probably the easiest
> solution.
>
> Best regards,
>
> Thomas
Thanks,
Valentin
More information about the buildroot
mailing list