Emerging into SYSROOT causes packages to install in host system
On Sunday 27 April 2008, Dave Bender wrote:
> I am attempting to cross compile x86 packages on an x86_64 host. In
> particular, when I attempt to emerge baselayout-2 into my SYSROOT path,
> emerge wants to emerge baselayout-2 into my host system. PORTAGE_CONFIGROOT
> is also set to the SYSROOT, so I do not understand why for example,
> package.mask on my host system is taken into account at all when emerge
> determines dependencies.
> I am following the instructions in Chapter 5 of the Embedded Gentoo
> Handbook to the letter and do not understand why this behaviour is
> occurring.
please post the exact commands as well as resulting output. us guessing at
what exactly you're doing simply causes confusion and wastes yours and our
time.
-mike
04-28-2008, 05:29 PM
"Dave Bender"
Emerging into SYSROOT causes packages to install in host system
Ned,
That is exactly the behaviour I see when I try to emerge other
packages like Xorg or cups on my server system. A year ago, I heard
the workaround is to determine all dependencies of a package and then
emerge each one with no-deps. That doesn't seem to be in the handbook
however.
Dave
On Mon, Apr 28, 2008 at 12:54 PM, Ned Ludd <solar@gentoo.org> wrote:
>
>
> On Mon, 2008-04-28 at 05:45 -0400, Mike Frysinger wrote:
> > On Sunday 27 April 2008, Dave Bender wrote:
> > > I am attempting to cross compile x86 packages on an x86_64 host. In
> > > particular, when I attempt to emerge baselayout-2 into my SYSROOT path,
> > > emerge wants to emerge baselayout-2 into my host system. PORTAGE_CONFIGROOT
> > > is also set to the SYSROOT, so I do not understand why for example,
> > > package.mask on my host system is taken into account at all when emerge
> > > determines dependencies.
> > > I am following the instructions in Chapter 5 of the Embedded Gentoo
> > > Handbook to the letter and do not understand why this behaviour is
> > > occurring.
> >
> > please post the exact commands as well as resulting output. us guessing at
> > what exactly you're doing simply causes confusion and wastes yours and our
> > time.
>
> Mike, actually I think I know the bug he is hitting.
> If portage sees that you have a dep not installed on / even if you pass
> ROOT=/somedir SYSCONFIG=/usr/$CTARGET ARCH=arm CHOST=arm-something
> emerge -pvq someapp ; you will get
> [ebuild N ] app-foo/bar
> [ebuild N ] app-foo/bar $ROOT
>
> So if you are using a wrapper and blindly start merging.. Cross compiled
> shit will end up on / despite you not asking for it. Zac says this is
> current expected behavior but I'd outright call it the most fscked up
> portage behavior ever along with the recent INSTALL_MASK= no longer
> working when using -K
>
>
--
gentoo-embedded@lists.gentoo.org mailing list
04-28-2008, 06:47 PM
"Dave Bender"
Emerging into SYSROOT causes packages to install in host system
Extended report:
As I mention in my earlier email, build host is x86_64, target is x86
(specifically c3 processor).
The xmerge command is an exact duplicate of the one presented in the
gentoo embedded handbook.
These are the packages that would be merged, in order:
Calculating dependencies |
!!! All ebuilds that could satisfy ">=sys-apps/baselayout-2.0.0" have
been masked.
!!! One of the following masked packages is required to complete your request:
- sys-apps/baselayout-2.0.0 (masked by: ~amd64 keyword)
For more information, see MASKED PACKAGES section in the emerge man page or
refer to the Gentoo Handbook.
(dependency required by "sys-apps/openrc-0.2.2" [ebuild])
So baselayout appears to be masked by ~amd64 keyword, which should be
irrelevant for cross compiling.
Thanks,
Dave
Other notes:
SYSROOT is populated with a /var and /tmp directory. /var contains
further subdirectories.
On Mon, Apr 28, 2008 at 1:29 PM, Dave Bender <codehero@gmail.com> wrote:
> Ned,
> That is exactly the behaviour I see when I try to emerge other
> packages like Xorg or cups on my server system. A year ago, I heard
> the workaround is to determine all dependencies of a package and then
> emerge each one with no-deps. That doesn't seem to be in the handbook
> however.
>
> Dave
>
> On Mon, Apr 28, 2008 at 12:54 PM, Ned Ludd <solar@gentoo.org> wrote:
> >
> >
>
>
> > On Mon, 2008-04-28 at 05:45 -0400, Mike Frysinger wrote:
> > > On Sunday 27 April 2008, Dave Bender wrote:
> > > > I am attempting to cross compile x86 packages on an x86_64 host. In
> > > > particular, when I attempt to emerge baselayout-2 into my SYSROOT path,
> > > > emerge wants to emerge baselayout-2 into my host system. PORTAGE_CONFIGROOT
> > > > is also set to the SYSROOT, so I do not understand why for example,
> > > > package.mask on my host system is taken into account at all when emerge
> > > > determines dependencies.
> > > > I am following the instructions in Chapter 5 of the Embedded Gentoo
> > > > Handbook to the letter and do not understand why this behaviour is
> > > > occurring.
> > >
> > > please post the exact commands as well as resulting output. us guessing at
> > > what exactly you're doing simply causes confusion and wastes yours and our
> > > time.
> >
> > Mike, actually I think I know the bug he is hitting.
> > If portage sees that you have a dep not installed on / even if you pass
> > ROOT=/somedir SYSCONFIG=/usr/$CTARGET ARCH=arm CHOST=arm-something
> > emerge -pvq someapp ; you will get
> > [ebuild N ] app-foo/bar
> > [ebuild N ] app-foo/bar $ROOT
> >
> > So if you are using a wrapper and blindly start merging.. Cross compiled
> > shit will end up on / despite you not asking for it. Zac says this is
> > current expected behavior but I'd outright call it the most fscked up
> > portage behavior ever along with the recent INSTALL_MASK= no longer
> > working when using -K
> >
> >
>
--
gentoo-embedded@lists.gentoo.org mailing list
04-28-2008, 07:21 PM
"Dave Bender"
Emerging into SYSROOT causes packages to install in host system
Matthijs,
That is currently the solution I use for x86. The drawbacks are
slower compilation performance (cross compilers running on 64 bit
empirically seem faster) and other overhead caused by chrooting. The
approach also does not extend to other architectures like ARM.
Essentially this approach is a lightweight emulation; taken to its
fullest extent you would be running QEMU to build for these other
architectures.
Dave
On Mon, Apr 28, 2008 at 3:07 PM, Matthijs Kooijman <matthijs@stdin.nl> wrote:
> Hi,
>
>
> > As I mention in my earlier email, build host is x86_64, target is x86
> > (specifically c3 processor).
> If your host is x86_64, wouldn't it make sense to use a x86 chroot as
> development host instead (which would run on your normal x86_64 kernel)? I
> have exactly this setup, and this prevents any sort of cross compilation from
> being necessary.
>
> Gr.
>
> Matthijs
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFIFiCAz0nQ5oovr7wRAs5SAJ0eT0RJIvSzemoFleJhgh skBTzSKQCfQIK3
> xnvNGgZ/hIiUxEUkNWMtFS0=
> =1dkQ
> -----END PGP SIGNATURE-----
>
>
--
gentoo-embedded@lists.gentoo.org mailing list
05-04-2008, 12:46 PM
Mike Frysinger
Emerging into SYSROOT causes packages to install in host system
On Monday 28 April 2008, Dave Bender wrote:
> That is currently the solution I use for x86. The drawbacks are
> slower compilation performance (cross compilers running on 64 bit
> empirically seem faster) and other overhead caused by chrooting. The
> approach also does not extend to other architectures like ARM.
> Essentially this approach is a lightweight emulation; taken to its
> fullest extent you would be running QEMU to build for these other
> architectures.
you could distcc with the host system. i dont know about "other overhead
caused by chrooting" though ... being in a chroot really adds no overhead at
all. while you can argue the non-native point if you were targeting
something non-native, Matthijs point is pretty clear: since you can easily do
native, you probably should as over all it will be a much smoother
development cycle.
-mike
05-04-2008, 01:31 PM
"Alon Bar-Lev"
Emerging into SYSROOT causes packages to install in host system
This is:
http://bugs.gentoo.org/show_bug.cgi?id=201499
Alon.
On 4/28/08, Dave Bender <codehero@gmail.com> wrote:
> Dear list,
> I am attempting to cross compile x86 packages on an x86_64 host. In particular,
> when I attempt to emerge baselayout-2 into my SYSROOT path, emerge wants to
> emerge baselayout-2 into my host system. PORTAGE_CONFIGROOT is also set to the
> SYSROOT, so I do not understand why for example, package.mask on my host system
> is taken into account at all when emerge determines dependencies.
> I am following the instructions in Chapter 5 of the Embedded Gentoo Handbook
> to the letter and do not understand why this behaviour is occurring.
>
> Thanks
> Dave
>
>
> --
> gentoo-embedded@lists.gentoo.org mailing list
>
>
--
gentoo-embedded@lists.gentoo.org mailing list
05-04-2008, 02:35 PM
"Dave Bender"
Emerging into SYSROOT causes packages to install in host system
On Sun, May 4, 2008 at 8:46 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Monday 28 April 2008, Dave Bender wrote:
>> That is currently the solution I use for x86. The drawbacks are
>> slower compilation performance (cross compilers running on 64 bit
>> empirically seem faster) and other overhead caused by chrooting. The
>> approach also does not extend to other architectures like ARM.
>> Essentially this approach is a lightweight emulation; taken to its
>> fullest extent you would be running QEMU to build for these other
>> architectures.
>
> you could distcc with the host system. i dont know about "other overhead
That's an interesting suggestion, I'll look into it.
> caused by chrooting" though ... being in a chroot really adds no overhead at
> all. while you can argue the non-native point if you were targeting
When I use 32bit chroots, some factor slows down file I/O a great
deal. For example I notice that emerge -uDN takes much
longer to do in a 32bit chroot. I use mount bind to share the
/usr/portage directory with the chroot, so I don't think its that
mechanism.
All I know is that updating inside the chroot is much slower.
> something non-native, Matthijs point is pretty clear: since you can easily do
> native, you probably should as over all it will be a much smoother
> development cycle.
Of course working natively always presents the fewest headaches. What
bugs me is that it seems so easy from the Embedded Handbook...
> -mike
>
--
gentoo-embedded@lists.gentoo.org mailing list
05-04-2008, 08:03 PM
"Gareth McClean"
Emerging into SYSROOT causes packages to install in host system
>When I use 32bit chroots, some factor slows down file I/O a great
>deal. For example I notice that emerge -uDN takes much
>longer to do in a 32bit chroot. I use mount bind to share the
>/usr/portage directory with the chroot, so I don't think its that
>mechanism.
>All I know is that updating inside the chroot is much slower.
Do you also mount /proc and /dev to your chroot using the --bind option?
-----Original Message-----
From: Dave Bender [mailto:codehero@gmail.com]
Sent: 04 May 2008 15:35
To: Mike Frysinger
Cc: gentoo-embedded@lists.gentoo.org
Subject: Re: [gentoo-embedded] Emerging into SYSROOT causes packages to
install in host system
<snip>
--
gentoo-embedded@lists.gentoo.org mailing list
05-04-2008, 09:46 PM
"Dave Bender"
Emerging into SYSROOT causes packages to install in host system
I mount bind to /dev; I just mount proc and sysfs normally (which I
think is OK, because they are not block devices)
On Sun, May 4, 2008 at 4:03 PM, Gareth McClean <disneysw@hotmail.com> wrote:
>>When I use 32bit chroots, some factor slows down file I/O a great
>>deal. For example I notice that emerge -uDN takes much
>>longer to do in a 32bit chroot. I use mount bind to share the
>>/usr/portage directory with the chroot, so I don't think its that
>>mechanism.
>>All I know is that updating inside the chroot is much slower.
>
>
>
> Do you also mount /proc and /dev to your chroot using the --bind option?
>
>
>
> -----Original Message-----
> From: Dave Bender [mailto:codehero@gmail.com]
> Sent: 04 May 2008 15:35
> To: Mike Frysinger
> Cc: gentoo-embedded@lists.gentoo.org
> Subject: Re: [gentoo-embedded] Emerging into SYSROOT causes packages to
> install in host system
>
> <snip>
>
>
> --
> gentoo-embedded@lists.gentoo.org mailing list
>
>
--
gentoo-embedded@lists.gentoo.org mailing list