[gentoo-user] cross-compile attempt

[gentoo-user] cross-compile attempt

[Mick]

[-- Attachment #1: Type: text/plain, Size: 3006 bytes --]

Hi All,

I am dipping my toe into cross-compile territory, in order to build i686 
binaries for a 32bit box, which is too old to do its own emerges.  I am using 
an amd64 box which is significantly faster to do all the heavy lifting and 
started applying this page:

https://wiki.gentoo.org/wiki/Embedded_Handbook/General/Creating_a_cross-compiler

which I followed up with:

https://wiki.gentoo.org/wiki/Cross_build_environment

and attempted to build @system:
=========================
# i686-pc-linux-gnu-emerge -uva @system

 * IMPORTANT: 3 news items need reading for repository 'gentoo'.
 * Use eselect news read to view new items.


These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N     ] sys-apps/busybox-1.24.2::gentoo to /usr/i686-pc-linux-gnu/ 
USE="make-symlinks static -debug -ipv6 -livecd -math -mdev -pam -savedconfig (-
selinux) -sep-usr -syslog -systemd" 0 KiB

Total: 1 package (1 new), Size of downloads: 0 KiB

Would you like to merge these packages? [Yes/No] y
 * ARCH is not set... Are you missing the '/usr/i686-pc-linux-
 * gnu/etc/portage/make.profile' symlink? Is the symlink correct? Is your
 * portage tree complete?
===============

As far as I can tell the link is there:

# ls -la /usr/i686-pc-linux-gnu/etc/portage/
total 8
drwxr-xr-x 1 root root   56 Jul 31 19:32 .
drwxr-xr-x 1 root root   20 Jul 31 18:32 ..
-rw-r--r-- 1 root root 1019 Jul 31 19:32 make.conf
lrwxrwxrwx 1 root root   30 Jul 31 17:48 make.profile -> 
/usr/portage/profiles/embedded
drwxr-xr-x 1 root root   32 Jul 31 18:16 profile

and it was created when I ran 'crossdev --stable -v -t i686-pc-linux-gnu'.

My make.conf looks like this:
==============================
# cat /usr/i686-pc-linux-gnu/etc/portage/make.conf 
CHOST=i686-pc-linux-gnu
CBUILD=x86_64-pc-linux-gnu
ARCH=x86

HOSTCC=x86_64-pc-linux-gnu-gcc

ROOT=/usr/${CHOST}/

ACCEPT_KEYWORDS="x86"

USE="${ARCH} -pam"

CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}"
MAKEOPTS="-j5"
AUTOCLEAN="yes"
USE="a52 aac aalib acpi apache2 -arts asf avi cdda cddb cdparanoia crypt css 
dri dts dv dvd dvdr dvdread divx -eds encode -esd flac fuse gif gimp gmedia -
gnome -gtk hpijs imlib -java lcms -libav live lzo mjpeg mmx mng modplug 
mozdevelop mp3 mysql ncurses npp nptlonly nsplugin pdf ppds quicktime real 
realmedia rtmp scanner semantic-desktop sse sse2 smp svg theora tiff usb utf8 
vcd vhosts vorbis vram v4l webdav wmf wmp xcomposite xine xinerama xulrunner 
xv xvid xvmc x264 yv12"
FEATURES="-collision-protect sandbox buildpkg noman noinfo nodoc"
# Be sure we dont overwrite pkgs from another repo..
PKGDIR=${ROOT}packages/
PORTAGE_TMPDIR=/var/tmp

ELIBC="glibc"

PKG_CONFIG_PATH="${ROOT}usr/lib/pkgconfig/"
#PORTDIR_OVERLAY="/usr/portage/local/"
============================


What am I missing?  How would/do you go about achieving the same objective?

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] cross-compile attempt

[Jeremi Piotrowski]

On Sun, Jul 31, 2016 at 07:40:37PM +0100, Mick wrote:
> 
>  * ARCH is not set... Are you missing the '/usr/i686-pc-linux-
>  * gnu/etc/portage/make.profile' symlink? Is the symlink correct? Is your
>  * portage tree complete?
> ===============
> 
> As far as I can tell the link is there:
> 
> # ls -la /usr/i686-pc-linux-gnu/etc/portage/
> total 8
> drwxr-xr-x 1 root root   56 Jul 31 19:32 .
> drwxr-xr-x 1 root root   20 Jul 31 18:32 ..
> -rw-r--r-- 1 root root 1019 Jul 31 19:32 make.conf
> lrwxrwxrwx 1 root root   30 Jul 31 17:48 make.profile -> 
> /usr/portage/profiles/embedded
> drwxr-xr-x 1 root root   32 Jul 31 18:16 profile
> 
> and it was created when I ran 'crossdev --stable -v -t i686-pc-linux-gnu'.
>

As far as I know, ARCH is one of those variables that has to be specified
in a profile, not in make.conf. A quick solution is to place the

    ARCH=x86

line into the site-specific override .../etc/portage/profile/make.defaults

Although in this case your choice of profile may simply be wrong. The
embedded profile is the crossdev default that pretty much only has
busybox. Choose something like default/linux/x86/13.0 or if you want a lighter
libc how about default/linux/uclibc/x86 (or hardened/linux/musl/x86). That
should give you a more complete @system set.

> 
> What am I missing?  How would/do you go about achieving the same objective?
> 

Since you are doing this on an amd64 box which can natively run x86, if
you want to achieve the same goal faster, start with a x86 stage3, chroot
into it and emerge a couple packages that you want to add, then tar it up
and load onto your 32 bit box. If you want to add packages later, emerge
them with '-b' in the chroot (on the amd64 box), and then follow

    https://wiki.gentoo.org/wiki/Binary_package_guide

to allow the 32-bit box to install them as binary packages.

Ofcourse if you want to learn crossdev, then this is a great chance to do
so.

Re: [gentoo-user] cross-compile attempt

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1784 bytes --]

On Sun, 31 Jul 2016 19:40:37 +0100 Mick wrote:
> Hi All,
> 
> I am dipping my toe into cross-compile territory, in order to build i686 
> binaries for a 32bit box, which is too old to do its own emerges.  I am using 
> an amd64 box which is significantly faster to do all the heavy lifting and 
> started applying this page:
> 
> https://wiki.gentoo.org/wiki/Embedded_Handbook/General/Creating_a_cross-compiler
> 
> which I followed up with:
> 
> https://wiki.gentoo.org/wiki/Cross_build_environment

And here comes this misconception again... Please, tell me, why on
the earth cross-compiling is needed for amd64 to produce i686
binaries?!

amd64 CPU _natively_ supports x86 instructions, amd64 kernel
natively supports x86 code (this can be disabled during kernel
config, but usually it isn't), amd64 gcc *can* produce x86 binaries.

There are two ways to help older x86 boxes to build packages faster:

1. Set up distcc to produce x86 code on your amd64 processors. Just
add -m32 to your *FLAGS.

2. Copy old box system to a chroot dir on amd64. Run setarch i686
and chroot to that directory, and build 32-bit packages as usual!
There are two ways to deliver them:

2.a. Generate binary packages on new box and install them on old
boxes.

2.b. Instead of copying old box's root, mount it over NFS.

I'm currently using 1, but planning to switch to 2.a, because
distcc can't help with everything (execution of java, python,
autotools and other stuff can't be helped with distcc).

I used 2.b earlier on very old box (it is dead now).

3. Well, one can do full cross-compilation as you proposed, but
this is ridiculous. Cross-compilation is always a pain and if it
can be avoided, it should be avoided.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-user] cross-compile attempt

[james]

On 07/31/2016 01:40 PM, Mick wrote:
> Hi All,
>
> I am dipping my toe into cross-compile territory, in order to build i686
> binaries for a 32bit box, which is too old to do its own emerges.

An excellent idea. As one who has performed the upgrade/downgrade 
surgery on many systems; the single biggest issue is burning up
old hard drives and mobos. Keep the old hardware as cool as possible.
I place them under the vents of a 'window AC' set as cold as possible.
I'm thinking about modifying and old fridge to get around 40 degrees F
and low humidity, with a ethernet hub inside and single hole for the
hub to outside cables, packed off with rubber grommets and silicon 
caulk. I'm tired of old hardware going dead on me....




> I am using
> an amd64 box which is significantly faster to do all the heavy lifting and
> started applying this page:
>
> https://wiki.gentoo.org/wiki/Embedded_Handbook/General/Creating_a_cross-compiler
>

Good reference. I would emphasize a few points.

1. Copy off (/var/lib/portage/world file and the /etc/*)
and others to another system.

2. Remove as many packages as possible before the compiling starts, 
including window managers. I now keep my profile(s), for both servers
and workstations, as simple as possible.

3. At the last stage put the packages back that you need/want to 
complete your tasks. Less complicated the packages are (KDE stands out) 
the easier the work and cross-compiling is.

HEAT is your enemy and HEAT's last name is Murphy.....


> which I followed up with:
>
> https://wiki.gentoo.org/wiki/Cross_build_environment
>
> and attempted to build @system:
> =========================
> # i686-pc-linux-gnu-emerge -uva @system
>
>  * IMPORTANT: 3 news items need reading for repository 'gentoo'.
>  * Use eselect news read to view new items.
>
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies... done!
> [ebuild  N     ] sys-apps/busybox-1.24.2::gentoo to /usr/i686-pc-linux-gnu/
> USE="make-symlinks static -debug -ipv6 -livecd -math -mdev -pam -savedconfig (-
> selinux) -sep-usr -syslog -systemd" 0 KiB
>
> Total: 1 package (1 new), Size of downloads: 0 KiB
>
> Would you like to merge these packages? [Yes/No] y
>  * ARCH is not set... Are you missing the '/usr/i686-pc-linux-
>  * gnu/etc/portage/make.profile' symlink? Is the symlink correct? Is your
>  * portage tree complete?
> ===============
>
> As far as I can tell the link is there:
>
> # ls -la /usr/i686-pc-linux-gnu/etc/portage/
> total 8
> drwxr-xr-x 1 root root   56 Jul 31 19:32 .
> drwxr-xr-x 1 root root   20 Jul 31 18:32 ..
> -rw-r--r-- 1 root root 1019 Jul 31 19:32 make.conf
> lrwxrwxrwx 1 root root   30 Jul 31 17:48 make.profile ->
> /usr/portage/profiles/embedded
> drwxr-xr-x 1 root root   32 Jul 31 18:16 profile
>
> and it was created when I ran 'crossdev --stable -v -t i686-pc-linux-gnu'.
>
> My make.conf looks like this:
> ==============================
> # cat /usr/i686-pc-linux-gnu/etc/portage/make.conf
> CHOST=i686-pc-linux-gnu
> CBUILD=x86_64-pc-linux-gnu
> ARCH=x86
>
> HOSTCC=x86_64-pc-linux-gnu-gcc
>
> ROOT=/usr/${CHOST}/
>
> ACCEPT_KEYWORDS="x86"
>
> USE="${ARCH} -pam"
>
> CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer"
> CXXFLAGS="${CFLAGS}"
> MAKEOPTS="-j5"
> AUTOCLEAN="yes"
> USE="a52 aac aalib acpi apache2 -arts asf avi cdda cddb cdparanoia crypt css
> dri dts dv dvd dvdr dvdread divx -eds encode -esd flac fuse gif gimp gmedia -
> gnome -gtk hpijs imlib -java lcms -libav live lzo mjpeg mmx mng modplug
> mozdevelop mp3 mysql ncurses npp nptlonly nsplugin pdf ppds quicktime real
> realmedia rtmp scanner semantic-desktop sse sse2 smp svg theora tiff usb utf8
> vcd vhosts vorbis vram v4l webdav wmf wmp xcomposite xine xinerama xulrunner
> xv xvid xvmc x264 yv12"
> FEATURES="-collision-protect sandbox buildpkg noman noinfo nodoc"
> # Be sure we dont overwrite pkgs from another repo..
> PKGDIR=${ROOT}packages/
> PORTAGE_TMPDIR=/var/tmp
>
> ELIBC="glibc"
>
> PKG_CONFIG_PATH="${ROOT}usr/lib/pkgconfig/"
> #PORTDIR_OVERLAY="/usr/portage/local/"
> ============================
>
>
> What am I missing?  How would/do you go about achieving the same objective?

The masters of gentoo cross compiling are mostly found on the 
gentoo-embedded channel, just so you know. Mostly  a collection of 
brilliant pricks and posers, but some kind kind-hearted folks therein too.


Cross compiling on clusters is a very hot area of interest right now, 
but that is not for the faint-at-heart, atm. I'd stick with the fastest 
multi-core single system you have access to and avoid distcc atm. ymmv.

hth,

James

Re: [gentoo-user] cross-compile attempt

[Mick]

[-- Attachment #1: Type: text/plain, Size: 3081 bytes --]

On Sunday 31 Jul 2016 23:18:00 Andrew Savchenko wrote:
> On Sun, 31 Jul 2016 19:40:37 +0100 Mick wrote:
> > Hi All,
> > 
> > I am dipping my toe into cross-compile territory, in order to build i686
> > binaries for a 32bit box, which is too old to do its own emerges.  I am
> > using an amd64 box which is significantly faster to do all the heavy
> > lifting and started applying this page:
> > 
> > https://wiki.gentoo.org/wiki/Embedded_Handbook/General/Creating_a_cross-co
> > mpiler
> > 
> > which I followed up with:
> > 
> > https://wiki.gentoo.org/wiki/Cross_build_environment
> 
> And here comes this misconception again... Please, tell me, why on
> the earth cross-compiling is needed for amd64 to produce i686
> binaries?!

I thought it did.  From what you're saying I got this wrong.  When I read the 
first use case bullet point, on the 2nd URL above, I thought I had arrived at 
the right place.  :-/


> amd64 CPU _natively_ supports x86 instructions, amd64 kernel
> natively supports x86 code (this can be disabled during kernel
> config, but usually it isn't), amd64 gcc *can* produce x86 binaries.

I thought amd64 can run x86 binaries, but I wasn't aware that it can compile 
them too, or what is needed to achieve this.  My knowledge on gcc is pretty 
much minimal.  I did search the Wiki, gentoo.org and Google for it, but all I 
could come across was cross-compiling.


> There are two ways to help older x86 boxes to build packages faster:
> 
> 1. Set up distcc to produce x86 code on your amd64 processors. Just
> add -m32 to your *FLAGS.

I read somewhere in these unsuccessful searches of mine that distcc is 
deprecated and it is better to use cross-compiling instead ... 


> 2. Copy old box system to a chroot dir on amd64. Run setarch i686
> and chroot to that directory, and build 32-bit packages as usual!
> There are two ways to deliver them:
> 
> 2.a. Generate binary packages on new box and install them on old
> boxes.

OK, I'll uninstall crossdev and try 2.a in the first instance.  Is there a Wiki 
page explaining what parts of the x86 system are needed to carry across to the 
amd64 guest_root_fs?  I wouldn't think I will need the whole x86 fs?  Anything 
else I need to pay attention to?


> 2.b. Instead of copying old box's root, mount it over NFS.

I'll look into this later, after I get 2.a going.
 

> I'm currently using 1, but planning to switch to 2.a, because
> distcc can't help with everything (execution of java, python,
> autotools and other stuff can't be helped with distcc).
> 
> I used 2.b earlier on very old box (it is dead now).
> 
> 3. Well, one can do full cross-compilation as you proposed, but
> this is ridiculous. Cross-compilation is always a pain and if it
> can be avoided, it should be avoided.

Thanks for this advice.  I am not particularly interested to use crossdev if 
it is not the best suited tool for the job, but I wasn't aware of the 
alternatives you suggested and haven't as yet found any HOWTOs on it.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] cross-compile attempt

[Mick]

[-- Attachment #1: Type: text/plain, Size: 3533 bytes --]

On Sunday 31 Jul 2016 23:31:29 you wrote:
> On Sunday 31 Jul 2016 23:18:00 Andrew Savchenko wrote:
> > On Sun, 31 Jul 2016 19:40:37 +0100 Mick wrote:
> > > Hi All,
> > > 
> > > I am dipping my toe into cross-compile territory, in order to build i686
> > > binaries for a 32bit box, which is too old to do its own emerges.  I am
> > > using an amd64 box which is significantly faster to do all the heavy
> > > lifting and started applying this page:
> > > 
> > > https://wiki.gentoo.org/wiki/Embedded_Handbook/General/Creating_a_cross-> > > co
> > > mpiler
> > > 
> > > which I followed up with:
> > > 
> > > https://wiki.gentoo.org/wiki/Cross_build_environment
> > 
> > And here comes this misconception again... Please, tell me, why on
> > the earth cross-compiling is needed for amd64 to produce i686
> > binaries?!
> 
> I thought it did.  From what you're saying I got this wrong.  When I read
> the first use case bullet point, on the 2nd URL above, I thought I had
> arrived at the right place.  :-/
> 
> > amd64 CPU _natively_ supports x86 instructions, amd64 kernel
> > natively supports x86 code (this can be disabled during kernel
> > config, but usually it isn't), amd64 gcc *can* produce x86 binaries.
> 
> I thought amd64 can run x86 binaries, but I wasn't aware that it can compile
> them too, or what is needed to achieve this.  My knowledge on gcc is pretty
> much minimal.  I did search the Wiki, gentoo.org and Google for it, but all
> I could come across was cross-compiling.
> 
> > There are two ways to help older x86 boxes to build packages faster:
> > 
> > 1. Set up distcc to produce x86 code on your amd64 processors. Just
> > add -m32 to your *FLAGS.
> 
> I read somewhere in these unsuccessful searches of mine that distcc is
> deprecated and it is better to use cross-compiling instead ...
> 
> > 2. Copy old box system to a chroot dir on amd64. Run setarch i686
> > and chroot to that directory, and build 32-bit packages as usual!
> > There are two ways to deliver them:
> > 
> > 2.a. Generate binary packages on new box and install them on old
> > boxes.
> 
> OK, I'll uninstall crossdev and try 2.a in the first instance.  Is there a
> Wiki page explaining what parts of the x86 system are needed to carry
> across to the amd64 guest_root_fs?  I wouldn't think I will need the whole
> x86 fs?  Anything else I need to pay attention to?
> 
> > 2.b. Instead of copying old box's root, mount it over NFS.
> 
> I'll look into this later, after I get 2.a going.
> 
> > I'm currently using 1, but planning to switch to 2.a, because
> > distcc can't help with everything (execution of java, python,
> > autotools and other stuff can't be helped with distcc).
> > 
> > I used 2.b earlier on very old box (it is dead now).
> > 
> > 3. Well, one can do full cross-compilation as you proposed, but
> > this is ridiculous. Cross-compilation is always a pain and if it
> > can be avoided, it should be avoided.
> 
> Thanks for this advice.  I am not particularly interested to use crossdev if
> it is not the best suited tool for the job, but I wasn't aware of the
> alternatives you suggested and haven't as yet found any HOWTOs on it.

Given Andrew's steer I had another look and found this guide:

https://wiki.gentoo.org/wiki/Project:AMD64/32-bit_Chroot_Guide

Is this approach still valid, or have things moved on since this article was 
authored (2012) and different configuration/approach is now recommended?

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] cross-compile attempt

[waltdnes]

On Sun, Jul 31, 2016 at 07:40:37PM +0100, Mick wrote
> Hi All,
> 
> I am dipping my toe into cross-compile territory, in order to build i686 
> binaries for a 32bit box, which is too old to do its own emerges.  I am using 
> an amd64 box which is significantly faster to do all the heavy lifting and 
> started applying this page:
> 
> https://wiki.gentoo.org/wiki/Embedded_Handbook/General/Creating_a_cross-compiler

  "True cross-compiling" is a pain.  It will not work for non trivial
stuff, which builds against glib/glibc and other system libraries,
unless you pull in a whole bunch of "compatability libraries" for the
target architecture.  On my "no-multilib" system, it doesn't work.
Sure, distcc "works transparently", but a bunch of builds get sent back
to the target machine to be done.  That defeats the whole point of
distcc, which is to do all the work on the more powerful machine...

  I recommend going with one of 3 "cheats"...

1) A 32-bit chroot in a 64-bit machine

2) A QEMU (or VirtualBox) 32-bit guest on a 64-bit host

3) If you have a spare 64-bit machine, install 32-bit Gentoo on it

  I use option 2) both as my distccd server and to manually build Pale
Moon.  The target in both cases is an ancient 32-bit-only Atom netbook.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] cross-compile attempt

[Peter Humphrey]

On Monday 01 Aug 2016 14:51:02 Mick wrote:

> Given Andrew's steer I had another look and found this guide:
> 
> https://wiki.gentoo.org/wiki/Project:AMD64/32-bit_Chroot_Guide
> 
> Is this approach still valid, or have things moved on since this article
> was authored (2012) and different configuration/approach is now
> recommended?

I use that method to maintain a 32-bit Atom box. I export its /usr/portage
via NFS to a chroot on this i7 box and build packages in the chroot. Then I
install from packages on the Atom.

I'm sure it would be just as easy, or more so, to mount the whole Atom file
system and work in it as though I had an i7 processor on the Atom file
system. I may try that again. Meanwhile, here's my /etc/init.d/atom script.
The mtab I copy in contains enough entries to forestall error messages:

$ cat /etc/init.d/atom
#!/sbin/openrc-run
depend() {
   need localmount
   need bootmisc
}
start() {
    ebegin "Mounting 32-bit chroot dirs under /mnt/atom"
    mount -t proc /proc /mnt/atom/proc
    mount --rbind /dev /mnt/atom/dev
    mount --rbind /sys /mnt/atom/sys
    mount --rbind /var/tmp/portage /mnt/atom/var/tmp/portage
    mount -t nfs 192.168.1.2:/usr/portage/packages /mnt/atom/usr/portage/packages
    cp /etc/mtab.atom /mnt/atom/etc/mtab
    eend $? "Error mounting 32-bit chroot directories"
}
stop() {
    ebegin "Unmounting 32-bit /mnt/atom chroot dirs"
    rm /mnt/atom/etc/mtab
    umount -f /mnt/atom/var/tmp/portage
    umount -f /mnt/atom/sys/firmware/efi/efivars
    umount -f /mnt/atom/sys/fs/pstore
    umount -f /mnt/atom/sys/fs/cgroup/openrc
    umount -f /mnt/atom/sys/fs/cgroup/cpuset
    umount -f /mnt/atom/sys/fs/cgroup/cpu
    umount -f /mnt/atom/sys/fs/cgroup/cpuacct
    umount -f /mnt/atom/sys/fs/cgroup/freezer
    umount -f /mnt/atom/sys/fs/cgroup
    umount -f /mnt/atom/sys/kernel/config
    umount -f /mnt/atom/sys/kernel/debug
    umount -f /mnt/atom/dev/pts
    umount -f /mnt/atom/dev/shm
    umount -f /mnt/atom/dev/mqueue
    umount -f /mnt/atom/proc
    umount -f /mnt/atom/sys
    umount -f /mnt/atom/dev
    umount -f /mnt/atom/usr/portage/packages
    eend $? "Error unmounting 32-bit chroot directories"
}

Of course I haven't bothered with idiot-proofing it, as I'm the only one
here.

HTH.

-- 
Rgds
Peter

[gentoo-user] Re: [was cross-compile attempt] 32bit chroot

[Mick]

[-- Attachment #1: Type: text/plain, Size: 1691 bytes --]

On Monday 01 Aug 2016 11:23:03 waltdnes@waltdnes.org wrote:

>   I recommend going with one of 3 "cheats"...
> 
> 1) A 32-bit chroot in a 64-bit machine
> 
> 2) A QEMU (or VirtualBox) 32-bit guest on a 64-bit host
> 
> 3) If you have a spare 64-bit machine, install 32-bit Gentoo on it
> 
>   I use option 2) both as my distccd server and to manually build Pale
> Moon.  The target in both cases is an ancient 32-bit-only Atom netbook.

I'm trying your cheat (1) above, but I must be doing something wrong:

gentoo-32bit # linux32 chroot /mnt/iso/gentoo-32bit /bin/bash
chroot: failed to run command ‘/bin/bash’: No such file or directory

gentoo-32bit # ls -la /bin/bash
-rwxr-xr-x 1 root root 705400 Jan  9  2016 /bin/bash

gentoo-32bit # ls -la ./bin/bash
-rwxr-xr-x 1 root root 677244 Jan 16  2016 ./bin/bash

gentoo-32bit # linux32 chroot /mnt/iso/gentoo-32bit ./bin/bash
chroot: failed to run command ‘./bin/bash’: No such file or directory

gentoo-32bit # mount | grep 32bit
dev on /mnt/iso/gentoo-32bit/dev type devtmpfs 
(rw,nosuid,relatime,size=10240k,nr_inodes=1915538,mode=755)
devpts on /mnt/iso/gentoo-32bit/dev/pts type devpts 
(rw,nosuid,noexec,relatime,gid=5,mode=620)
shm on /mnt/iso/gentoo-32bit/dev/shm type tmpfs 
(rw,nosuid,nodev,noexec,relatime)
proc on /mnt/iso/gentoo-32bit/proc type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on /mnt/iso/gentoo-32bit/sys type sysfs 
(rw,nosuid,nodev,noexec,relatime)
/dev/sdb3 on /mnt/iso/gentoo-32bit/usr/portage type btrfs 
(rw,noatime,space_cache,subvolid=5,subvol=/)
tmpfs on /mnt/iso/gentoo-32bit/tmp type tmpfs (rw,nosuid,noatime,nodiratime)

Any clues?
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] cross-compile attempt

[Mick]

[-- Attachment #1: Type: text/plain, Size: 2737 bytes --]

On Monday 01 Aug 2016 16:31:18 Peter Humphrey wrote:
> On Monday 01 Aug 2016 14:51:02 Mick wrote:
> > Given Andrew's steer I had another look and found this guide:
> > 
> > https://wiki.gentoo.org/wiki/Project:AMD64/32-bit_Chroot_Guide
> > 
> > Is this approach still valid, or have things moved on since this article
> > was authored (2012) and different configuration/approach is now
> > recommended?
> 
> I use that method to maintain a 32-bit Atom box. I export its /usr/portage
> via NFS to a chroot on this i7 box and build packages in the chroot. Then I
> install from packages on the Atom.
> 
> I'm sure it would be just as easy, or more so, to mount the whole Atom file
> system and work in it as though I had an i7 processor on the Atom file
> system. I may try that again. Meanwhile, here's my /etc/init.d/atom script.
> The mtab I copy in contains enough entries to forestall error messages:
> 
> $ cat /etc/init.d/atom
> #!/sbin/openrc-run
> depend() {
>    need localmount
>    need bootmisc
> }
> start() {
>     ebegin "Mounting 32-bit chroot dirs under /mnt/atom"
>     mount -t proc /proc /mnt/atom/proc
>     mount --rbind /dev /mnt/atom/dev
>     mount --rbind /sys /mnt/atom/sys
>     mount --rbind /var/tmp/portage /mnt/atom/var/tmp/portage
>     mount -t nfs 192.168.1.2:/usr/portage/packages
> /mnt/atom/usr/portage/packages cp /etc/mtab.atom /mnt/atom/etc/mtab
>     eend $? "Error mounting 32-bit chroot directories"
> }
> stop() {
>     ebegin "Unmounting 32-bit /mnt/atom chroot dirs"
>     rm /mnt/atom/etc/mtab
>     umount -f /mnt/atom/var/tmp/portage
>     umount -f /mnt/atom/sys/firmware/efi/efivars
>     umount -f /mnt/atom/sys/fs/pstore
>     umount -f /mnt/atom/sys/fs/cgroup/openrc
>     umount -f /mnt/atom/sys/fs/cgroup/cpuset
>     umount -f /mnt/atom/sys/fs/cgroup/cpu
>     umount -f /mnt/atom/sys/fs/cgroup/cpuacct
>     umount -f /mnt/atom/sys/fs/cgroup/freezer
>     umount -f /mnt/atom/sys/fs/cgroup
>     umount -f /mnt/atom/sys/kernel/config
>     umount -f /mnt/atom/sys/kernel/debug
>     umount -f /mnt/atom/dev/pts
>     umount -f /mnt/atom/dev/shm
>     umount -f /mnt/atom/dev/mqueue
>     umount -f /mnt/atom/proc
>     umount -f /mnt/atom/sys
>     umount -f /mnt/atom/dev
>     umount -f /mnt/atom/usr/portage/packages
>     eend $? "Error unmounting 32-bit chroot directories"
> }
> 
> Of course I haven't bothered with idiot-proofing it, as I'm the only one
> here.
> 
> HTH.

Thank you Peter, I seem to have posted a few seconds before I received your 
message.  From what you're showing above I seem to have not performed a 
correct mount of the chroot fs.  I better rinse and repeat ...
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] Re: [was cross-compile attempt] 32bit chroot

[waltdnes]

On Mon, Aug 01, 2016 at 04:46:24PM +0100, Mick wrote
> On Monday 01 Aug 2016 11:23:03 waltdnes@waltdnes.org wrote:
> 
> >   I recommend going with one of 3 "cheats"...
> > 
> > 1) A 32-bit chroot in a 64-bit machine
> > 
> > 2) A QEMU (or VirtualBox) 32-bit guest on a 64-bit host
> > 
> > 3) If you have a spare 64-bit machine, install 32-bit Gentoo on it
> > 
> >   I use option 2) both as my distccd server and to manually build Pale
> > Moon.  The target in both cases is an ancient 32-bit-only Atom netbook.
> 
> I'm trying your cheat (1) above, but I must be doing something wrong:
> 
> gentoo-32bit # linux32 chroot /mnt/iso/gentoo-32bit /bin/bash
> chroot: failed to run command ???/bin/bash???: No such file or directory
> 
> gentoo-32bit # ls -la /bin/bash
> -rwxr-xr-x 1 root root 705400 Jan  9  2016 /bin/bash
> 
> gentoo-32bit # ls -la ./bin/bash
> -rwxr-xr-x 1 root root 677244 Jan 16  2016 ./bin/bash
> 
> gentoo-32bit # linux32 chroot /mnt/iso/gentoo-32bit ./bin/bash
> chroot: failed to run command ???./bin/bash???: No such file or directory

  I believe that "/bin/bash" is the pathname after you switch to the
chroot environment.  So you would need a 32-bit bash located at
/mnt/iso/gentoo-32bit/bin/bash *BEFORE CHROOTING*.  See
https://lwn.net/Articles/252794/

> What chroot() actually does is fairly simple, it modifies pathname
> lookups for a process and its children so that any reference to a path
> starting '/' will effectively have the new root, which is passed as
> the single argument, prepended onto the path. The current working
> directory is left unchanged and relative paths can still refer to
> files outside of the new root.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] cross-compile attempt

[Mick]

[-- Attachment #1: Type: text/plain, Size: 2650 bytes --]

On Monday 01 Aug 2016 16:49:15 Mick wrote:

> Thank you Peter, I seem to have posted a few seconds before I received your
> message.  From what you're showing above I seem to have not performed a
> correct mount of the chroot fs.  I better rinse and repeat ...

Hmm ... I followed the handbook this time to make sure all is correctly 
mounted:

gentoo-32bit # mount | grep 32bit
proc on /mnt/iso/gentoo-32bit/proc type proc (rw,relatime)
sysfs on /mnt/iso/gentoo-32bit/sys type sysfs 
(rw,nosuid,nodev,noexec,relatime)
debugfs on /mnt/iso/gentoo-32bit/sys/kernel/debug type debugfs 
(rw,nosuid,nodev,noexec,relatime)
fusectl on /mnt/iso/gentoo-32bit/sys/fs/fuse/connections type fusectl 
(rw,nosuid,nodev,noexec,relatime)
efivarfs on /mnt/iso/gentoo-32bit/sys/firmware/efi/efivars type efivarfs 
(rw,nosuid,nodev,noexec,relatime)
cgroup_root on /mnt/iso/gentoo-32bit/sys/fs/cgroup type tmpfs 
(rw,nosuid,nodev,noexec,relatime,size=10240k,mode=755)
openrc on /mnt/iso/gentoo-32bit/sys/fs/cgroup/openrc type cgroup 
(rw,nosuid,nodev,noexec,relatime,release_agent=/lib64/rc/sh/cgroup-release-
agent.sh,name=openrc)
cpuset on /mnt/iso/gentoo-32bit/sys/fs/cgroup/cpuset type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpuset)
cpu on /mnt/iso/gentoo-32bit/sys/fs/cgroup/cpu type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpu)
cpuacct on /mnt/iso/gentoo-32bit/sys/fs/cgroup/cpuacct type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpuacct)
blkio on /mnt/iso/gentoo-32bit/sys/fs/cgroup/blkio type cgroup 
(rw,nosuid,nodev,noexec,relatime,blkio)
freezer on /mnt/iso/gentoo-32bit/sys/fs/cgroup/freezer type cgroup 
(rw,nosuid,nodev,noexec,relatime,freezer)
net_cls on /mnt/iso/gentoo-32bit/sys/fs/cgroup/net_cls type cgroup 
(rw,nosuid,nodev,noexec,relatime,net_cls)
net_prio on /mnt/iso/gentoo-32bit/sys/fs/cgroup/net_prio type cgroup 
(rw,nosuid,nodev,noexec,relatime,net_prio)
pids on /mnt/iso/gentoo-32bit/sys/fs/cgroup/pids type cgroup 
(rw,nosuid,nodev,noexec,relatime,pids)
dev on /mnt/iso/gentoo-32bit/dev type devtmpfs 
(rw,nosuid,relatime,size=10240k,nr_inodes=1915538,mode=755)
mqueue on /mnt/iso/gentoo-32bit/dev/mqueue type mqueue 
(rw,nosuid,nodev,noexec,relatime)
devpts on /mnt/iso/gentoo-32bit/dev/pts type devpts 
(rw,nosuid,noexec,relatime,gid=5,mode=620)
shm on /mnt/iso/gentoo-32bit/dev/shm type tmpfs 
(rw,nosuid,nodev,noexec,relatime)


I must be doing some newbie error ... because I still get:

gentoo-32bit # linux32 chroot /mnt/iso/gentoo-32bit /bin/bash
chroot: failed to run command ‘/bin/bash’: No such file or directory


what would this error be?  :-/

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] Re: [was cross-compile attempt] 32bit chroot

[Mick]

[-- Attachment #1: Type: text/plain, Size: 2385 bytes --]

On Monday 01 Aug 2016 12:19:41 waltdnes@waltdnes.org wrote:
> On Mon, Aug 01, 2016 at 04:46:24PM +0100, Mick wrote
> 
> > On Monday 01 Aug 2016 11:23:03 waltdnes@waltdnes.org wrote:
> > >   I recommend going with one of 3 "cheats"...
> > > 
> > > 1) A 32-bit chroot in a 64-bit machine
> > > 
> > > 2) A QEMU (or VirtualBox) 32-bit guest on a 64-bit host
> > > 
> > > 3) If you have a spare 64-bit machine, install 32-bit Gentoo on it
> > > 
> > >   I use option 2) both as my distccd server and to manually build Pale
> > > 
> > > Moon.  The target in both cases is an ancient 32-bit-only Atom netbook.
> > 
> > I'm trying your cheat (1) above, but I must be doing something wrong:
> > 
> > gentoo-32bit # linux32 chroot /mnt/iso/gentoo-32bit /bin/bash
> > chroot: failed to run command ???/bin/bash???: No such file or directory
> > 
> > gentoo-32bit # ls -la /bin/bash
> > -rwxr-xr-x 1 root root 705400 Jan  9  2016 /bin/bash
> > 
> > gentoo-32bit # ls -la ./bin/bash
> > -rwxr-xr-x 1 root root 677244 Jan 16  2016 ./bin/bash
> > 
> > gentoo-32bit # linux32 chroot /mnt/iso/gentoo-32bit ./bin/bash
> > chroot: failed to run command ???./bin/bash???: No such file or directory
> 
>   I believe that "/bin/bash" is the pathname after you switch to the
> chroot environment.  So you would need a 32-bit bash located at
> /mnt/iso/gentoo-32bit/bin/bash *BEFORE CHROOTING*.  See
> https://lwn.net/Articles/252794/
> 
> > What chroot() actually does is fairly simple, it modifies pathname
> > lookups for a process and its children so that any reference to a path
> > starting '/' will effectively have the new root, which is passed as
> > the single argument, prepended onto the path. The current working
> > directory is left unchanged and relative paths can still refer to
> > files outside of the new root.

Thanks Walter, it's present along with the whole of the 32bit OS fs:

gentoo-32bit # ls -la /mnt/iso/gentoo-32bit/bin/bash
-rwxr-xr-x 1 root root 677244 Jan 16  2016 /mnt/iso/gentoo-32bit/bin/bash

gentoo-32bit # file /mnt/iso/gentoo-32bit/bin/bash
/mnt/iso/gentoo-32bit/bin/bash: ELF 32-bit LSB executable, Intel 80386, 
version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for 
GNU/Linux 2.6.32, stripped


Am I missing something in the amd64 kernel to be able to execute 32bit code?
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] Re: [was cross-compile attempt] 32bit chroot

[Mick]

[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]

On Monday 01 Aug 2016 17:32:58 Mick wrote:
> On Monday 01 Aug 2016 12:19:41 waltdnes@waltdnes.org wrote:

> > > What chroot() actually does is fairly simple, it modifies pathname
> > > lookups for a process and its children so that any reference to a path
> > > starting '/' will effectively have the new root, which is passed as
> > > the single argument, prepended onto the path. The current working
> > > directory is left unchanged and relative paths can still refer to
> > > files outside of the new root.
> 
> Thanks Walter, it's present along with the whole of the 32bit OS fs:
> 
> gentoo-32bit # ls -la /mnt/iso/gentoo-32bit/bin/bash
> -rwxr-xr-x 1 root root 677244 Jan 16  2016 /mnt/iso/gentoo-32bit/bin/bash
> 
> gentoo-32bit # file /mnt/iso/gentoo-32bit/bin/bash
> /mnt/iso/gentoo-32bit/bin/bash: ELF 32-bit LSB executable, Intel 80386,
> version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for
> GNU/Linux 2.6.32, stripped
> 
> 
> Am I missing something in the amd64 kernel to be able to execute 32bit code?

No, I was missing the *whole* of the 32bit fs /lib directory.  O_O

Apologies for the noise.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] Re: [was cross-compile attempt] 32bit chroot

[Mick]

[-- Attachment #1: Type: text/plain, Size: 2069 bytes --]

On Monday 01 Aug 2016 18:57:53 Mick wrote:
> On Monday 01 Aug 2016 17:32:58 Mick wrote:
> > On Monday 01 Aug 2016 12:19:41 waltdnes@waltdnes.org wrote:
> > > > What chroot() actually does is fairly simple, it modifies pathname
> > > > lookups for a process and its children so that any reference to a path
> > > > starting '/' will effectively have the new root, which is passed as
> > > > the single argument, prepended onto the path. The current working
> > > > directory is left unchanged and relative paths can still refer to
> > > > files outside of the new root.
> > 
> > Thanks Walter, it's present along with the whole of the 32bit OS fs:
> > 
> > gentoo-32bit # ls -la /mnt/iso/gentoo-32bit/bin/bash
> > -rwxr-xr-x 1 root root 677244 Jan 16  2016 /mnt/iso/gentoo-32bit/bin/bash
> > 
> > gentoo-32bit # file /mnt/iso/gentoo-32bit/bin/bash
> > /mnt/iso/gentoo-32bit/bin/bash: ELF 32-bit LSB executable, Intel 80386,
> > version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for
> > GNU/Linux 2.6.32, stripped
> > 
> > 
> > Am I missing something in the amd64 kernel to be able to execute 32bit
> > code?
> No, I was missing the *whole* of the 32bit fs /lib directory.  O_O
> 
> Apologies for the noise.

I think libreoffice, chromium and firefox will be compiled in a chroot from now 
on and then emerged as binaries.  This is the difference for libreoffice:

     Sat Aug 29 06:09:09 2015 >>> app-office/libreoffice-4.4.4.3
       merge time: 15 hours, 34 minutes and 2 seconds.

     Sun Sep 13 01:36:03 2015 >>> app-office/libreoffice-4.4.5.2
       merge time: 15 hours, 13 minutes and 17 seconds.

     Sun Nov 29 02:30:04 2015 >>> app-office/libreoffice-5.0.3.2
       merge time: 16 hours, 54 minutes and 28 seconds.

     Sun Mar 27 09:31:20 2016 >>> app-office/libreoffice-5.0.5.2
       merge time: 17 hours and 8 seconds.

     Mon Aug  1 22:17:15 2016 >>> app-office/libreoffice-5.1.4.2
       merge time: 1 minute and 31 seconds.

(chromium takes even longer!)  :-)

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] Re: [was cross-compile attempt] 32bit chroot

[Jeremi Piotrowski]

On Mon, Aug 01, 2016 at 10:21:20PM +0100, Mick wrote:
> 
> I think libreoffice, chromium and firefox will be compiled in a chroot from now 
> on and then emerged as binaries.  This is the difference for libreoffice:
> 
>      Sat Aug 29 06:09:09 2015 >>> app-office/libreoffice-4.4.4.3
>        merge time: 15 hours, 34 minutes and 2 seconds.
> 
>      Sun Sep 13 01:36:03 2015 >>> app-office/libreoffice-4.4.5.2
>        merge time: 15 hours, 13 minutes and 17 seconds.
> 
>      Sun Nov 29 02:30:04 2015 >>> app-office/libreoffice-5.0.3.2
>        merge time: 16 hours, 54 minutes and 28 seconds.
> 
>      Sun Mar 27 09:31:20 2016 >>> app-office/libreoffice-5.0.5.2
>        merge time: 17 hours and 8 seconds.
> 
>      Mon Aug  1 22:17:15 2016 >>> app-office/libreoffice-5.1.4.2
>        merge time: 1 minute and 31 seconds.
> 
> (chromium takes even longer!)  :-)
>

Does it make sense to compile your own versions of these packages and then
binary merge, when portage already contains binary ebuilds for these
packages? (firefox-bin/libreoffice-bin/google-chrome)

Re: [gentoo-user] Re: [was cross-compile attempt] 32bit chroot

[waltdnes]

On Tue, Aug 02, 2016 at 01:11:24AM +0200, Jeremi Piotrowski wrote

> Does it make sense to compile your own versions of these packages
> and then binary merge, when portage already contains binary ebuilds
> for these packages? (firefox-bin/libreoffice-bin/google-chrome)

  I've got an underpowered netbook that needs all the help it can get.
I build in the VM with...

-O2 -march=bonnell -mfpmath=sse -pipe -fomit-frame-pointer -fno-unwind-tables -fno-asynchronous-unwind-tables

  Even older desktops benefit.  One case in point is my former Dell
D530 Core2 Duo.  When Gentoo had been installed, it could not keep up
with the slowest stream of NHL Gamecenter Live.  Everything was generic
x86 with SSE2 thrown in, from the stage3.  After re-emerging system and
world optimized for the machine's cpu, it could keep up with not only
the lowest quality stream, but a medium-quality stream.  So yes, it
helps.

  From http://gentoo-en.vfose.ru/wiki/Safe_Cflags#-march.3Dnative to
find out exactly what your cpu is, run the following command on the
*TARGET* machine...

gcc -march=native -E -v - </dev/null 2>&1 | grep cc1

  Ignore the flag output, which may be over-optimistic.  Just look at
what it says for "-march=".

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Re: [was cross-compile attempt] 32bit chroot

[Mick]

[-- Attachment #1: Type: text/plain, Size: 1660 bytes --]

On Tuesday 02 Aug 2016 00:33:57 waltdnes@waltdnes.org wrote:
> On Tue, Aug 02, 2016 at 01:11:24AM +0200, Jeremi Piotrowski wrote
> 
> > Does it make sense to compile your own versions of these packages
> > and then binary merge, when portage already contains binary ebuilds
> > for these packages? (firefox-bin/libreoffice-bin/google-chrome)
> 
>   I've got an underpowered netbook that needs all the help it can get.
> I build in the VM with...
> 
> -O2 -march=bonnell -mfpmath=sse -pipe -fomit-frame-pointer
> -fno-unwind-tables -fno-asynchronous-unwind-tables
> 
>   Even older desktops benefit.  One case in point is my former Dell
> D530 Core2 Duo.  When Gentoo had been installed, it could not keep up
> with the slowest stream of NHL Gamecenter Live.  Everything was generic
> x86 with SSE2 thrown in, from the stage3.  After re-emerging system and
> world optimized for the machine's cpu, it could keep up with not only
> the lowest quality stream, but a medium-quality stream.  So yes, it
> helps.
> 
>   From http://gentoo-en.vfose.ru/wiki/Safe_Cflags#-march.3Dnative to
> find out exactly what your cpu is, run the following command on the
> *TARGET* machine...
> 
> gcc -march=native -E -v - </dev/null 2>&1 | grep cc1
> 
>   Ignore the flag output, which may be over-optimistic.  Just look at
> what it says for "-march=".

Yes, I've had similar experiences here with own built binaries being faster 
than generic *-bin packages offered by portage.  The 32bit box in question is 
running a single core Pentium4 ... I could bet it feels slower than my 
AppleTV1 with its 1.00GHz Pentium-M.  :-)
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] cross-compile attempt

[Peter Humphrey]

On Monday 01 Aug 2016 17:21:52 Mick wrote:
> On Monday 01 Aug 2016 16:49:15 Mick wrote:
> > Thank you Peter, I seem to have posted a few seconds before I received
> > your message.  From what you're showing above I seem to have not
> > performed a correct mount of the chroot fs.  I better rinse and repeat
> > ...
> 
> Hmm ... I followed the handbook this time to make sure all is correctly
> mounted:
> 
> gentoo-32bit # mount | grep 32bit
> proc on /mnt/iso/gentoo-32bit/proc type proc (rw,relatime)
> sysfs on /mnt/iso/gentoo-32bit/sys type sysfs
> (rw,nosuid,nodev,noexec,relatime)
> debugfs on /mnt/iso/gentoo-32bit/sys/kernel/debug type debugfs
> (rw,nosuid,nodev,noexec,relatime)
> fusectl on /mnt/iso/gentoo-32bit/sys/fs/fuse/connections type fusectl
> (rw,nosuid,nodev,noexec,relatime)
> efivarfs on /mnt/iso/gentoo-32bit/sys/firmware/efi/efivars type efivarfs
> (rw,nosuid,nodev,noexec,relatime)
> cgroup_root on /mnt/iso/gentoo-32bit/sys/fs/cgroup type tmpfs
> (rw,nosuid,nodev,noexec,relatime,size=10240k,mode=755)
> openrc on /mnt/iso/gentoo-32bit/sys/fs/cgroup/openrc type cgroup
> (rw,nosuid,nodev,noexec,relatime,release_agent=/lib64/rc/sh/cgroup-release
> - agent.sh,name=openrc)
> cpuset on /mnt/iso/gentoo-32bit/sys/fs/cgroup/cpuset type cgroup
> (rw,nosuid,nodev,noexec,relatime,cpuset)
> cpu on /mnt/iso/gentoo-32bit/sys/fs/cgroup/cpu type cgroup
> (rw,nosuid,nodev,noexec,relatime,cpu)
> cpuacct on /mnt/iso/gentoo-32bit/sys/fs/cgroup/cpuacct type cgroup
> (rw,nosuid,nodev,noexec,relatime,cpuacct)
> blkio on /mnt/iso/gentoo-32bit/sys/fs/cgroup/blkio type cgroup
> (rw,nosuid,nodev,noexec,relatime,blkio)
> freezer on /mnt/iso/gentoo-32bit/sys/fs/cgroup/freezer type cgroup
> (rw,nosuid,nodev,noexec,relatime,freezer)
> net_cls on /mnt/iso/gentoo-32bit/sys/fs/cgroup/net_cls type cgroup
> (rw,nosuid,nodev,noexec,relatime,net_cls)
> net_prio on /mnt/iso/gentoo-32bit/sys/fs/cgroup/net_prio type cgroup
> (rw,nosuid,nodev,noexec,relatime,net_prio)
> pids on /mnt/iso/gentoo-32bit/sys/fs/cgroup/pids type cgroup
> (rw,nosuid,nodev,noexec,relatime,pids)
> dev on /mnt/iso/gentoo-32bit/dev type devtmpfs
> (rw,nosuid,relatime,size=10240k,nr_inodes=1915538,mode=755)
> mqueue on /mnt/iso/gentoo-32bit/dev/mqueue type mqueue
> (rw,nosuid,nodev,noexec,relatime)
> devpts on /mnt/iso/gentoo-32bit/dev/pts type devpts
> (rw,nosuid,noexec,relatime,gid=5,mode=620)
> shm on /mnt/iso/gentoo-32bit/dev/shm type tmpfs
> (rw,nosuid,nodev,noexec,relatime)
> 
> 
> I must be doing some newbie error ... because I still get:
> 
> gentoo-32bit # linux32 chroot /mnt/iso/gentoo-32bit /bin/bash
> chroot: failed to run command ‘/bin/bash’: No such file or directory
> 
> 
> what would this error be?  :-/

I can't see your 32-bit file-system in that list. It couldn't be that 
simple, could it?

-- 
Rgds
Peter

Re: [gentoo-user] Re: [was cross-compile attempt] 32bit chroot

[Peter Humphrey]

On Monday 01 Aug 2016 18:57:53 Mick wrote:
> On Monday 01 Aug 2016 17:32:58 Mick wrote:

--->8

> > Am I missing something in the amd64 kernel to be able to execute 32bit
> > code?
> No, I was missing the *whole* of the 32bit fs /lib directory.  O_O

Oops. I wasn't going to own up to this, but a week or two ago I managed to 
wipe out my entire /lib64 directory with some careless copy-and-pasting. I 
couldn't even shut the machine down and had to pull the plug.

I wouldn't have minded so much but I'd only just finished building the 
system on the plasma profile and hadn't yet backed it up. It took me over a 
week to get established again, what with the current fragility of the whole 
plasma system.

:(

-- 
Rgds
Peter

Re: [gentoo-user] cross-compile attempt

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 668 bytes --]

On Mon, 01 Aug 2016 16:49:15 +0100, Mick wrote:

> Thank you Peter, I seem to have posted a few seconds before I received
> your message.  From what you're showing above I seem to have not
> performed a correct mount of the chroot fs.  I better rinse and
> repeat ...

If you are using systemd, it is much simpler to use a container with
systemd-nspawn that chroot, it takes care of all the mucking around
required to get /dev, /proc and friends available to the container.

The only mount I need to take care of myself is for $PKGDIR, which is
also available via NFS on the target box.


-- 
Neil Bothwick

Top Oxymorons Number 21: "Now, then ..."

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] Re: [was cross-compile attempt] 32bit chroot

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 794 bytes --]

On Tue, 02 Aug 2016 10:22:09 +0100, Peter Humphrey wrote:

> > No, I was missing the *whole* of the 32bit fs /lib directory.  O_O  
> 
> Oops. I wasn't going to own up to this, but a week or two ago I managed
> to wipe out my entire /lib64 directory with some careless
> copy-and-pasting. I couldn't even shut the machine down and had to pull
> the plug.

I recently had a package giving problems, I couldn't downgrade through
portage because the old version was gone, but I still had a binary
package so I untarred it into /.

It replaced my /lib symlink with a directory containing just the one file
from that package. Then I started wondering why virtually nothing worked :(


-- 
Neil Bothwick

Bus: (n.) a connector you plug money into, something like a slot machine.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[gentoo-user] Re: cross-compile attempt

[Ian Zimmerman]

On 2016-08-02 12:56 +0100, Neil Bothwick wrote:

> If you are using systemd, it is much simpler to use a container with
> systemd-nspawn that chroot, it takes care of all the mucking around
> required to get /dev, /proc and friends available to the container.
> 
> The only mount I need to take care of myself is for $PKGDIR, which is
> also available via NFS on the target box.

Even with chroot and without without systemd, it pays to create a dead
simple shell script that does all the mounting.  You can even have that
script itself exec chroot as the last step.

-- 
Please *no* private Cc: on mailing lists and newsgroups
Why does the arrow on Hillary signs point to the right?

Re: [gentoo-user] Re: cross-compile attempt

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 864 bytes --]

On Tue, 2 Aug 2016 17:26:09 -0700, Ian Zimmerman wrote:

> > If you are using systemd, it is much simpler to use a container with
> > systemd-nspawn that chroot, it takes care of all the mucking around
> > required to get /dev, /proc and friends available to the container.
> > 
> > The only mount I need to take care of myself is for $PKGDIR, which is
> > also available via NFS on the target box.  
> 
> Even with chroot and without without systemd, it pays to create a dead
> simple shell script that does all the mounting.  You can even have that
> script itself exec chroot as the last step.

That's what I do, only the script is even simpler now ;-)

While containers are simpler, it is still easy to miss out a step, so a
script makes a lot of sense.


-- 
Neil Bothwick

Member, National Association For Tagline Assimilators (NAFTA)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] Re: cross-compile attempt

[james]

On 08/03/2016 03:20 AM, Neil Bothwick wrote:
> On Tue, 2 Aug 2016 17:26:09 -0700, Ian Zimmerman wrote:
>
>>> If you are using systemd, it is much simpler to use a container with
>>> systemd-nspawn that chroot, it takes care of all the mucking around
>>> required to get /dev, /proc and friends available to the container.
>>>
>>> The only mount I need to take care of myself is for $PKGDIR, which is
>>> also available via NFS on the target box.
>>
>> Even with chroot and without without systemd, it pays to create a dead
>> simple shell script that does all the mounting.  You can even have that
>> script itself exec chroot as the last step.
>
> That's what I do, only the script is even simpler now ;-)
>
> While containers are simpler, it is still easy to miss out a step, so a
> script makes a lot of sense.
>
>

OK, so now I curious to try this out too. I'd be interested in testing
this script for a hardware system (situation) exactly identical to Mick.
I do not use systemd. If someone wanted to post a  script via gist
(http://www.labnol.org/internet/github-gist-tutorial/) or elsewhere
or privately or via private email, centric to openrc, I'd test it out,
for a variety of final target image needs.

Also any other scripts for arm64v8 builds on native arm64 systems would
be of keen interest to me. I'd settle for a script for armv7 to use as a
starting point.



James

Re: [gentoo-user] Re: cross-compile attempt

[R0b0t1]

On Wed, Aug 3, 2016 at 12:26 PM, james <garftd@verizon.net> wrote:
> On 08/03/2016 03:20 AM, Neil Bothwick wrote:
>>
>> On Tue, 2 Aug 2016 17:26:09 -0700, Ian Zimmerman wrote:
>>
>>>> If you are using systemd, it is much simpler to use a container with
>>>> systemd-nspawn that chroot, it takes care of all the mucking around
>>>> required to get /dev, /proc and friends available to the container.
>>>>
>>>> The only mount I need to take care of myself is for $PKGDIR, which is
>>>> also available via NFS on the target box.
>>>
>>>
>>> Even with chroot and without without systemd, it pays to create a dead
>>> simple shell script that does all the mounting.  You can even have that
>>> script itself exec chroot as the last step.
>>
>>
>> That's what I do, only the script is even simpler now ;-)
>>
>> While containers are simpler, it is still easy to miss out a step, so a
>> script makes a lot of sense.
>>
>>
>
> OK, so now I curious to try this out too. I'd be interested in testing
> this script for a hardware system (situation) exactly identical to Mick.
> I do not use systemd. If someone wanted to post a  script via gist
> (http://www.labnol.org/internet/github-gist-tutorial/) or elsewhere
> or privately or via private email, centric to openrc, I'd test it out,
> for a variety of final target image needs.
>
> Also any other scripts for arm64v8 builds on native arm64 systems would
> be of keen interest to me. I'd settle for a script for armv7 to use as a
> starting point.
>
>
>
> James
>

You can compile for i386 natively with the multi-target libraries
installed. I have used a chroot instead when my system was installed
without the i386 libraries.

My other thought was using a cross compiler, but I was running out of
disk space at the time and needed to support multiple systems. The
major issue here is it is hard (or cumbersome) to keep partial
systems; each crossdev prefix will be a self-contained system.