Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

  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