From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [autobuild.buildroot.net] Build results for 2018-04-09
Date: Tue, 10 Apr 2018 10:23:29 +0200 [thread overview]
Message-ID: <20180410102329.3109623f@windsurf> (raw)
In-Reply-To: <c4f7202a-5609-9c3d-81b8-9209fe7497e4@smile.fr>
Hello,
On Tue, 10 Apr 2018 10:15:29 +0200, Valentin Korenblit wrote:
> We have the following problem: llvm-config (host version installed in STAGING_DIR)
> is not being able to link correctly with the libc of the host system. This happens
> in the following scenario: target architecture = x86_64 and target libc != glibc
> (assuming host system has glibc).
>
> As the RPATH specifies $ORIGIN/../lib and the binary is located in STAGING_DIR/usr/bin,
> it tries to link with the libc of the target, resulting in:
While the build is running, the rpath is not $ORIGIN/../lib. The RPATH
in the host and staging directories are only changed from an absolute
path to $ORIGIN/../lib in the "make sdk" target.
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".
> ./llvm-config: error while loading shared libraries: libc.so.0: cannot open shared object file:
> No such file or directory.
>
> It is important that llvm-config is located in STAGING, as it returns linker flags and
> include directories relative to its location:
>
> For example, when installed in STAGING_DIR/usr/bin:
>
> ./llvm-config --ldflags
> -L/home/vakor/buildroot/output/host/x86_64-buildroot-linux-uclibc/sysroot/usr/lib
>
> But when installed in HOST_DIR/bin
>
> ./llvm-config --ldflags
> -L/home/vakor/buildroot/output/host/lib
>
> The quick solution would be to change the RPATH to HOST_DIR/lib after copying it to STAGING,
> so we'll also need either chrpath or patchelf. Otherwise, we can do a wrapper script in
> STAGING that calls llvm-config from host, but this will have some outputs that are hardcoded
> and will be more difficult to maintain in case llvm-config is modified in future versions.
>
> I would like to know which would be an appropriate solution for this, any suggestions are
> welcome.
One possibility is to do like we do for postgresql: provide our own
minimal -config script. See package/postgresql/pg_config for an example.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2018-04-10 8:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-10 6:00 [Buildroot] [autobuild.buildroot.net] Build results for 2018-04-09 Thomas Petazzoni
2018-04-10 8:15 ` Valentin Korenblit
2018-04-10 8:23 ` Thomas Petazzoni [this message]
2018-04-10 8:35 ` Valentin Korenblit
2018-04-10 8:41 ` Thomas Petazzoni
2018-04-10 9:02 ` Valentin Korenblit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180410102329.3109623f@windsurf \
--to=thomas.petazzoni@bootlin.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox