[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20194.8535.854625.466329@quad.stoffel.home>
Date: Fri, 9 Dec 2011 09:55:19 -0500
From: "John Stoffel" <john@...ffel.org>
To: Colin Walters <walters@...bum.org>
Cc: John Stoffel <john@...ffel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: chroot(2) and bind mounts as non-root
>>>>> "Colin" == Colin Walters <walters@...bum.org> writes:
Colin> 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?
Colin> Yes, something like that; basically it's about ensuring that
Colin> the libfoo we're building binaries against is
Colin> /home/walters/build/libfoo.so and not /usr/lib/libfoo.so.
Colin> I'm actually intending for the core build system of my OS to
Colin> work in *both* cross and native compilation. That means it's
Colin> important to keep them as close as possible.
Colin> What you were talking about above (i.e. "just don't chroot") is
Colin> what http://buildroot.net does (and others, I also
Colin> semi-maintain GNOME's jhbuild). It works if you're very
Colin> careful in your build scripts, know and carefully propagate the
Colin> large set of magic environment variables, etc., then yes, you
Colin> can do it.
Colin> But chroot is just so nice a hammer for this nail.
I can see that, but maybe you can still fix this in userspace using
the schroot tool others have mentioned.
John
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists