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
next prev 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