All of lore.kernel.org
 help / color / mirror / Atom feed
From: Colin Walters <walters@verbum.org>
To: John Stoffel <john@stoffel.org>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: chroot(2) and bind mounts as non-root
Date: Thu, 08 Dec 2011 13:26:40 -0500	[thread overview]
Message-ID: <1323368800.10724.73.camel@lenny> (raw)
In-Reply-To: <20192.65168.140290.462594@quad.stoffel.home>

On Thu, 2011-12-08 at 13:14 -0500, John Stoffel wrote:

> Or is it because you're trying to edit on one OS, such a fedora 14,
> then build and debug inside an Debian 5.0 setup?  But without running
> a completely seperate system, but just doing a chroot into a new
> filesystem tree?  

Yes, something like that; basically it's about ensuring that the libfoo
we're building binaries against is /home/walters/build/libfoo.so and
not /usr/lib/libfoo.so.

I'm actually intending for the core build system of my OS to work in
*both* cross and native compilation.  That means it's important to keep
them as close as possible.

What you were talking about above (i.e. "just don't chroot") is what
http://buildroot.net does (and others, I also semi-maintain GNOME's
jhbuild).  It works if you're very careful in your build scripts, know
and carefully propagate the large set of magic environment variables,
etc., then yes, you can do it.

But chroot is just so nice a hammer for this nail.




  reply	other threads:[~2011-12-08 18:27 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-07 17:54 chroot(2) and bind mounts as non-root Colin Walters
2011-12-07 19:36 ` John Stoffel
2011-12-08 16:10   ` Colin Walters
2011-12-08 18:14     ` John Stoffel
2011-12-08 18:26       ` Colin Walters [this message]
2011-12-09  0:49         ` Sven-Haegar Koch
2011-12-09 14:55         ` John Stoffel
2011-12-09 15:06           ` Colin Walters
2011-12-08 17:04   ` Arnd Bergmann
2011-12-08 17:15     ` Colin Walters
2011-12-07 19:40 ` Andy Lutomirski
2011-12-08 16:58   ` Colin Walters
2011-12-07 20:34 ` H. Peter Anvin
2011-12-07 20:54   ` Alan Cox
2011-12-15 18:55     ` Andrew G. Morgan
2011-12-16 15:44       ` Colin Walters
2011-12-18  1:22         ` Andrew G. Morgan
2011-12-18 15:19           ` Colin Walters
2011-12-10  5:29 ` Serge E. Hallyn
2011-12-12 16:41   ` Colin Walters
2011-12-12 23:11     ` Serge E. Hallyn
2011-12-15 20:56       ` Colin Walters
2011-12-16  6:14         ` Eric W. Biederman
2011-12-18 16:01           ` Colin Walters
2011-12-19  0:55             ` Eric W. Biederman
2011-12-19  4:06               ` Serge E. Hallyn
2011-12-19  9:22                 ` Eric W. Biederman
2011-12-20 16:49                   ` Colin Walters
2011-12-20 21:23               ` Colin Walters
2011-12-21 18:15           ` Steve Grubb
2012-01-03 23:13             ` Eric W. Biederman

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=1323368800.10724.73.camel@lenny \
    --to=walters@verbum.org \
    --cc=john@stoffel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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.