Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] Potential lurking issue with host rpaths
Date: Thu, 26 Dec 2019 15:49:01 +0100	[thread overview]
Message-ID: <20191226154901.66683ec5@windsurf> (raw)
In-Reply-To: <20191225151351.GO26395@scaer>

Hello,

On Wed, 25 Dec 2019 16:13:51 +0100
"Yann E. MORIN" <yann.morin.1998@free.fr> wrote:

> - without PPD
>   - libfoo not installed on the host system
>     - host-libfoo built before host-bar
>       - bar links to libfoo
>         - bar has an RPATH for another lib
>           => OK  
>         - bar does not have an RPATH for another lib
>           -> check-host-rpath errors out for host-bar
>           => OK  
>     - host-libfoo built after host-bar
>       -> bar not linked to libfoo
>       => OK  
> 
>   - libfoo installed on the host system
>     - host-libfoo built before host-bar
>       - bar links to host-libfoo
>         - bar has an RPATH for another lib
>           => OK  
>         - bar does not have an RPATH for another lib
>           -> check-host-rpath errors out for host-bar
>           => OK  
>     - host-libfoo built after host-bar
>       - bar links to system libfoo
>         - bar has an RPATH for another lib
>           -> check-host-rpath OK for both host-bar and host-libfoo
>           -> error at runtime: bar uses host-libfoo instead of system  
>              libfoo
>           => KO, MISSED  

True, but I'm not sure what we can do here. The only thing we can do is
to add all the appropriate --disable-<foo> options to make sure host-bar
doesn't link with any optional library that we don't have as a
dependency.

> - with PPD
>   - libfoo not installed on the host system
>     -> bar never linked to libfoo
>     => OK  
> 
>   - libfoo installed on the host system
>     -> bar always linked to system libfoo  
>       - bar has an RPATH for another lib
>         -> check-host-rpath OK for host-bar
>         -> error at runtime: bar uses host-libfoo instead of system  
>            libfoo, *but* only once the final, complete host directory
>            has been aggregated
>         => KO, MISSED  

Absolutely. This is indeed a weird thing with the PPD stuff: during the
build of Buildroot, we are never using what is going to be the final
SDK. I'm not sure what we can do about it though, except as suggested
above, ensures we have as much as possible the appropriate
--disable-<foo>, but obviously this is never going to be perfect: new
optional dependencies are going to be added by upstream, and we will
not notice them.

A (crazy?) idea is perhaps to check against which libraries host
binaries/libraries end up being linked with. They should only be linked
against:

 - Other libraries in HOST_DIR

 - A small reduced set of system libraries, which we could have a
   whitelist (libc, libm, librt, libgcc_s, libatomic, etc.).

If one of our host program links against something else from the host
system, then it is not good, and we should error out. At least this
would allow us to *detect* such issues, and hopefully thanks to that
add the appropriate --disable-<foo> options where needed. The user
would also be clearly notified that there is something not good going
on with one of the host packages.

Other ideas ?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

      reply	other threads:[~2019-12-26 14:49 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-25 15:13 [Buildroot] Potential lurking issue with host rpaths Yann E. MORIN
2019-12-26 14:49 ` Thomas Petazzoni [this message]

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=20191226154901.66683ec5@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