Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Korsgaard <peter@korsgaard.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 5/6] core: check host executables have appropriate RPATH
Date: Wed, 18 Nov 2015 22:46:16 +0100	[thread overview]
Message-ID: <87fv03aslz.fsf@dell.be.48ers.dk> (raw)
In-Reply-To: <8e0bfbb455c19c606ff0b9996a1508f145f4eec7.1447449754.git.yann.morin.1998@free.fr> (Yann E. MORIN's message of "Fri, 13 Nov 2015 22:48:51 +0100")

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

 > When we build our host programs, and they depend on a host library we
 > also build, we want to ensure that program actually uses that library at
 > runtime, and not the one from the system.

 > We currently ensure that in two ways:
 >   - we add a RPATH tag that points to our host library directory,
 >   - we export LD_LIBRARY_PATH to point to that same directory.

 > With thse two in place, we're pretty much confident that our host
 > libraries will be used by our host programs.

 > However, it turns our that not all the host programs we build end up
 > with an RPATH tag:
 >   - some packages do not use our $(HOST_LDFLAGS)
 >   - some packages' build system are oblivious to those LDFLAGS

 > In this case, there are two situation:
 >   - the program is not linked to one of our host libraries: it in fact
 >     does not need an RPATH tag [0]
 >   - the program actually uses one of our host libraries: in that case it
 >     should have had an RPATH tag pointing to the host directory.

 > As for libraries, it is unclear whether they should or should not have
 > an RPATH pointing to our host directory. as for programs, it is only
 > important they have such an RPATH if they have a dependency on another
 > host lbrary we build. But even though, in practice this is not an issue,
 > because the program that loads such a libray does have an RPATH (it did
 > find that library!), so the RPATH from the program is also used to
 > search for second-level (and third-level...) dependencies, as well as
 > for libraries loaded via dlopen().

 > We add a new support script that checks that all ELF executables have
 > a proper DT_RPATH (or DT_RUNPATH) tag when they link to our host
 > libraries, and reports those file that are missing an RPATH. If a file
 > missing an RPATH is an executable, the script aborts; if only libraries
 > are are missing an RPATH, the script does not abort.

 > [0] Except if it were to dlopen() it, of course, but the only program
 > I'm aware of that does that is openssl, and it has a correct RPATH tag.

 > Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
 > Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
 > Cc: Arnout Vandecappelle <arnout@mind.be>
 > Cc: Peter Korsgaard <jacmet@uclibc.org>

Committed, thanks.

-- 
Bye, Peter Korsgaard

  parent reply	other threads:[~2015-11-18 21:46 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-13 21:48 [Buildroot] [PATCH 0/6] core: ditch LD_LIBRARY_PATH (branch yem/no-ld-library-path) Yann E. MORIN
2015-11-13 21:48 ` [Buildroot] [PATCH 1/6] package/axfsutils: fix Makefile Yann E. MORIN
2015-11-15 16:44   ` Arnout Vandecappelle
2015-11-17  9:08   ` Peter Korsgaard
2015-11-13 21:48 ` [Buildroot] [PATCH 2/6] package/mysql: unconditionally define host variables Yann E. MORIN
2015-11-15 16:59   ` Arnout Vandecappelle
2015-11-17  9:09   ` Peter Korsgaard
2015-11-13 21:48 ` [Buildroot] [PATCH 3/6] package/perl-file-util: remove host variant Yann E. MORIN
2015-11-15 19:19   ` Arnout Vandecappelle
2015-11-17  9:09   ` Peter Korsgaard
2015-11-13 21:48 ` [Buildroot] [PATCH 4/6] package/libcurl: carefully override LD_LIBRARY_PATH Yann E. MORIN
2015-11-15 19:27   ` Arnout Vandecappelle
2015-11-17  9:09   ` Peter Korsgaard
2015-11-13 21:48 ` [Buildroot] [PATCH 5/6] core: check host executables have appropriate RPATH Yann E. MORIN
2015-11-14  9:52   ` Yann E. MORIN
2015-11-15 21:49   ` Arnout Vandecappelle
2015-11-16 23:54     ` Yann E. MORIN
2015-11-18 21:46   ` Peter Korsgaard [this message]
2015-11-13 21:48 ` [Buildroot] [PATCH 6/6] core/pkg-infrastructures: remove LD_LIBRARY_PATH from the environment Yann E. MORIN
2015-11-18 21:46   ` Peter Korsgaard
2015-11-15 21:54 ` [Buildroot] [PATCH 0/6] core: ditch LD_LIBRARY_PATH (branch yem/no-ld-library-path) Arnout Vandecappelle

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=87fv03aslz.fsf@dell.be.48ers.dk \
    --to=peter@korsgaard.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