All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v7 5/9] core: sanitize RPATH in host tree at the very end of the build
Date: Thu, 20 Jul 2017 16:06:32 +0200	[thread overview]
Message-ID: <20170720160632.37698930@windsurf> (raw)
In-Reply-To: <2f8b3ab3-b2e6-d444-9981-bd07bfc250b8@mind.be>

Hello,

On Thu, 20 Jul 2017 15:58:49 +0200, Arnout Vandecappelle wrote:

> >>  Also, host-finalize (or sdk) should depend on toolchain, and probably also on
> >> $(filter host-%,$(PACKAGES)). The latter is currently incomplete, but when we
> >> get around to selecting BR2_PACKAGE_HOST_* for all host packages, we will make
> >> sure that 'make sdk' really generates the complete sdk.  
> > 
> > For the SDK, you also need to build all the target packages. The SDK
> > contains the sysroot (i.e STAGING_DIR), where the target packages
> > install libraries and headers.  
> 
>  This is what I wrote in an earlier reply to Wolfgang.

Yes, I was replying as I was reading the thread, and saw your other
reply afterwards.

> > Basically, sdk needs to depend on "world".  
> 
>  Not really, it doesn't need to depend on target-finalize or the rootfs targets.

Correct, but I am not sure it is really worth being smart here.

> >>  And finally, I think that the staging sanitization fits better here than in
> >> target-finalize. It has nothing to do with target, and the only reason that we
> >> do such sanitization is to make the sdk relocatable.  
> > 
> > The sanitization in staging and target has nothing to do with making
> > the SDK relocatable. Why do you think it's related ?  
> 
>  target indeed has nothing to do with making the SDK relocatable. It is only
> needed to deal with stupid packages that don't correctly use --prefix/DESTDIR
> and that end up putting the full absolute build-time directory in rpath.

Agreed.

>  staging is different. Sanitizing staging is not really needed, in the sense
> that any rpath in there is simply not going to be used. We want to sanitize
> staging for the following reasons:
> 
> - To avoid leaking references to the original output directory. This way, we can
> validate that the SDK is relocatable by running a simple "grep -r ${BASE_DIR}
> ${HOST_DIR}". Obviously RPATH sanitization is not sufficient (e.g. also the
> references to source files have to be stripped), but it's a step in the right
> direction. This reason is obviously only relevant for the SDK.
> 
> - To make sure that when an executable is copied to target that it actually
> executes correctly. Since within Buildroot we never copy stuff from staging to
> target, this is clearly only relevant for the SDK.

OK, makes sense. I indeed believe having those details in the commit
log or in the code would be nice.

So do we agree that:

 - target sanitization will be done in target-finalize

 - staging sanitization will be done in "make sdk"

 - host sanitization will be done in "make sdk"

Correct ?

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

  reply	other threads:[~2017-07-20 14:06 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-05 16:53 [Buildroot] [PATCH v7 0/9] Make the SDK relocatable Wolfgang Grandegger
2017-07-05 16:53 ` [Buildroot] [PATCH v7 1/9] package/patchelf: add patch for rpath sanitization under a root directory Wolfgang Grandegger
2017-07-19 21:08   ` Arnout Vandecappelle
2017-07-20  6:55     ` Wolfgang Grandegger
2017-07-20  7:55       ` Arnout Vandecappelle
2017-07-20  8:05         ` Wolfgang Grandegger
2017-07-19 23:17   ` Arnout Vandecappelle
2017-07-20  7:33     ` Wolfgang Grandegger
2017-07-05 16:53 ` [Buildroot] [PATCH v7 2/9] support/scripts: add fix-rpath script to sanitize the rpath Wolfgang Grandegger
2017-07-19 23:02   ` Arnout Vandecappelle
2017-07-20  7:31     ` Wolfgang Grandegger
2017-07-20  8:15       ` Arnout Vandecappelle
2017-07-20  9:03         ` Wolfgang Grandegger
2017-07-20 13:45           ` Arnout Vandecappelle
2017-07-20 14:08             ` Wolfgang Grandegger
2017-07-20 14:19               ` Arnout Vandecappelle
2017-07-20 16:50                 ` Wolfgang Grandegger
2017-07-20 17:05                   ` Arnout Vandecappelle
2017-07-05 16:53 ` [Buildroot] [PATCH v7 3/9] core: sanitize RPATH in staging tree at the end of target finalization Wolfgang Grandegger
2017-07-19 23:31   ` Arnout Vandecappelle
2017-07-05 16:53 ` [Buildroot] [PATCH v7 4/9] core: sanitize RPATH in target " Wolfgang Grandegger
2017-07-19 23:34   ` Arnout Vandecappelle
2017-07-20  8:25     ` Wolfgang Grandegger
2017-07-20  8:52       ` Arnout Vandecappelle
2017-07-05 16:53 ` [Buildroot] [PATCH v7 5/9] core: sanitize RPATH in host tree at the very end of the build Wolfgang Grandegger
2017-07-19 23:51   ` Arnout Vandecappelle
2017-07-20  8:40     ` Wolfgang Grandegger
2017-07-20  8:49       ` Arnout Vandecappelle
2017-07-20  9:15         ` Wolfgang Grandegger
2017-07-20 10:45           ` Arnout Vandecappelle
2017-07-20 13:45             ` Thomas Petazzoni
2017-07-20 13:44     ` Thomas Petazzoni
2017-07-20 13:58       ` Arnout Vandecappelle
2017-07-20 14:06         ` Thomas Petazzoni [this message]
2017-07-20 14:16           ` Arnout Vandecappelle
2017-07-05 16:53 ` [Buildroot] [PATCH v7 6/9] core: install relocation script and location at the " Wolfgang Grandegger
2017-07-19 23:58   ` Arnout Vandecappelle
2017-07-05 16:53 ` [Buildroot] [PATCH v7 7/9] external-toolchain: check if a buildroot SDK has already been relocated Wolfgang Grandegger
2017-07-20  0:12   ` Arnout Vandecappelle
2017-07-05 16:53 ` [Buildroot] [PATCH v7 8/9] support/scripts: relocate-sdk.sh now creates sdk-location in share/buildroot Wolfgang Grandegger
2017-07-20  0:13   ` Arnout Vandecappelle
2017-07-20 13:47   ` Thomas Petazzoni
2017-07-05 16:53 ` [Buildroot] [PATCH v7 9/9] package/qt5base: provide "qt.conf" to make "qmake" relocatable Wolfgang Grandegger
2017-07-20 13:49 ` [Buildroot] [PATCH v7 0/9] Make the SDK relocatable Thomas Petazzoni

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=20170720160632.37698930@windsurf \
    --to=thomas.petazzoni@free-electrons.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.