[gentoo-user] gcc-6.4.0-r1::gentoo failed (compile phase)

[gentoo-user] gcc-6.4.0-r1::gentoo failed (compile phase)

[thelma]

I've switched one of my older box to desktop profile-17 updated gcc to 6.4.0-r1 and it compile just fine.
But when I do  emerge -e @world
recompile gcc-6.4.0-r1 get stuck on"

* One or more packages are either masked or have missing dependencies:
 * 
 *   >=dev-libs/mpfr-2.4.2:0/0= pulled in by:
 *     (sys-devel/gcc-6.4.0-r1:6.4.0/6.4.0::gentoo, installed)

emerge --info
Portage 2.3.24 (python 3.5.4-final-0, default/linux/amd64/17.0/desktop, gcc-6.4.0, glibc-2.25-r10, 4.9.6-gentoo-r1 x86_64)
=================================================================
System uname: Linux-4.9.6-gentoo-r1-x86_64-Intel-R-_Atom-TM-_CPU_330_@_1.60GHz-with-gentoo-2.4.1
KiB Mem:     2038868 total,    807572 free
KiB Swap:    2097148 total,   2047452 free
Timestamp of repository gentoo: Wed, 14 Mar 2018 18:00:01 +0000
Head commit of repository gentoo: 04417076a13a10d172b6e00d22f04ffa128eae38
sh bash 4.4_p12
ld GNU ld (Gentoo 2.28 p1.2) 2.28
app-shells/bash:          4.4_p12::gentoo
dev-java/java-config:     2.2.0-r3::gentoo
dev-lang/perl:            5.24.3::gentoo
dev-lang/python:          2.7.14-r1::gentoo, 3.4.5::gentoo, 3.5.4-r1::gentoo
dev-util/cmake:           3.9.6::gentoo
dev-util/pkgconfig:       0.29.2::gentoo
sys-apps/baselayout:      2.4.1-r2::gentoo
sys-apps/openrc:          0.34.11::gentoo
sys-apps/sandbox:         2.12::gentoo
sys-devel/autoconf:       2.13::gentoo, 2.69-r4::gentoo
sys-devel/automake:       1.11.6-r3::gentoo, 1.15.1-r2::gentoo
sys-devel/binutils:       2.28-r2::gentoo, 2.29.1-r1::gentoo
sys-devel/gcc:            4.9.4::gentoo, 5.4.0-r3::gentoo, 6.4.0-r1::gentoo
sys-devel/gcc-config:     1.8-r1::gentoo
sys-devel/libtool:        2.4.6-r3::gentoo
sys-devel/make:           4.2.1::gentoo
sys-kernel/linux-headers: 4.13::gentoo (virtual/os-headers)
sys-libs/glibc:           2.25-r10::gentoo
Repositories:

gentoo
    location: /usr/portage
    sync-type: rsync
    sync-uri: rsync://10.10.0.6/gentoo-portage
    priority: -1000
    sync-rsync-extra-opts: 
    sync-rsync-verify-metamanifest: no

Local
    location: /usr/local/portage
    masters: gentoo
    priority: 99999999

ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="* -@EULA PUEL dlj-1.1 Oracle-BCLA-JavaSE"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=core2 -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /opt/brother/scanner/brscan4/brsanenetdevice4.cfg /usr/lib64/fax /usr/share/easy-rsa /usr/share/gnupg/qualified.txt /var/spool/fax/etc"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-march=core2 -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="--autounmask-write=y --keep-going --with-bdeps=y"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync multilib-strict news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="ftp://ftp.gtlib.gatech.edu/pub/gentoo http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror"
LANG="en_US.utf8"
LC_ALL="en_US.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j5"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"
PORTAGE_TMPDIR="/var/tmp"
USE="X a52 aac acpi alsa amd64 apache2 berkdb bluetooth branding brandingdvd bzip2 cairo cdda cdr cgi cli consolekit crypt cups cxx dbus dri dts dvd dvdr emboss encode exif fam flac foomaticdb fortran gdbm gif gimp gimpprint glamor gpm gtk iconv ipv6 java jpeg lcms ldap libnotify lm_sensors lock mad mmx mng modules mp3 mp4 mpeg multilib mysql ncurses nls nplt nptl ogg opengl openmp pam pango pcre pdf png policykit ppds qt3support qt5 readline scanner sdl seccomp session spell sse sse2 ssl startup-notification svg tcpd tetex thunar tiff truetype type1 udev udisks unicode upower usb vorbis wxwidgets x264 xattr xcb xml xv xvid zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="mmx mmxext sse sse2 sse3 ssse3" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="evdev" KERNEL="linux" L10N="en" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-6" POSTGRES_TARGETS="postgres9_5" PYTHON_SINGLE_TARGET="python3_5" PYTHON_TARGETS="python2_7 python3_5" RUBY_TARGETS="ruby22 ruby23" SANE_BACKENDS="fujitsu" USERLAND="GNU" VIDEO_CARDS="intel vesa" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LINGUAS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

-- 
Thelma

Re: [gentoo-user] gcc-6.4.0-r1::gentoo failed (compile phase)

[Helmut Jarausch]

On 03/26/2018 01:30:19 PM, thelma@sys-concept.com wrote:
> I've switched one of my older box to desktop profile-17 updated gcc  
> to 6.4.0-r1 and it compile just fine.
> But when I do  emerge -e @world
> recompile gcc-6.4.0-r1 get stuck on"
> 
> * One or more packages are either masked or have missing dependencies:
>  *
>  *   >=dev-libs/mpfr-2.4.2:0/0= pulled in by:
>  *     (sys-devel/gcc-6.4.0-r1:6.4.0/6.4.0::gentoo, installed)
> 

I'd try to emerge dev-libs/mpfr  (version 3.1.6 is on stable) first.

Helmut

Re: [gentoo-user] [SOLVED] gcc-6.4.0-r1::gentoo failed (compile phase)

[thelma]

On 03/27/2018 03:19 AM, Helmut Jarausch wrote:
> On 03/26/2018 01:30:19 PM, thelma@sys-concept.com wrote:
>> I've switched one of my older box to desktop profile-17 updated gcc to
>> 6.4.0-r1 and it compile just fine.
>> But when I do  emerge -e @world
>> recompile gcc-6.4.0-r1 get stuck on"
>>
>> * One or more packages are either masked or have missing dependencies:
>>  *
>>  *   >=dev-libs/mpfr-2.4.2:0/0= pulled in by:
>>  *     (sys-devel/gcc-6.4.0-r1:6.4.0/6.4.0::gentoo, installed)
>>
> 
> I'd try to emerge dev-libs/mpfr  (version 3.1.6 is on stable) first.
> 
> Helmut

I did emerged "dev-libs/mpfr" (I'm on latest stable) gcc-6.4.0.-r1 still
failed to compile itself with MAKEOPTS="-j5"

SOLVED!
The gcc-6.4.0-r1 compiled with
MAKEOPTS="-j1"

What is strange is that this is the second low profile system that
gcc-6.4.0-r1 failed to compile large package. My other boxed was 4-core
and 4GB of RAM and I had to switch to MAKEOPTS="-j1"

The above system is: Intel(R) Atom(TM) CPU 330 @ 1.60GHz with 2GB of RAM
and "gcc-4.9.4" compiled "gcc-6.4.0-r1" with MAKEOPTS="-j5" OK
but when I switched/upgrade profile to "gcc-6.4.0-r1" it filed to
compile gcc-6.4.0 with MAKEOPTS="-j5"
I had lower MAKEOPTS to -j1

So it seems to me the gcc-6.4.0-r1 much more resource hungry or there is
a bug in it.
--
Thelma

Re: [gentoo-user] [SOLVED] gcc-6.4.0-r1::gentoo failed (compile phase)

[Peter Humphrey]

On Tuesday, 27 March 2018 16:25:10 BST thelma@sys-concept.com wrote:
> SOLVED!
> The gcc-6.4.0-r1 compiled with
> MAKEOPTS="-j1"
> 
> What is strange is that this is the second low profile system that
> gcc-6.4.0-r1 failed to compile large package. My other boxed was 4-core
> and 4GB of RAM and I had to switch to MAKEOPTS="-j1"
> 
> The above system is: Intel(R) Atom(TM) CPU 330 @ 1.60GHz with 2GB of RAM
> and "gcc-4.9.4" compiled "gcc-6.4.0-r1" with MAKEOPTS="-j5" OK
> but when I switched/upgrade profile to "gcc-6.4.0-r1" it filed to
> compile gcc-6.4.0 with MAKEOPTS="-j5"
> I had lower MAKEOPTS to -j1
> 
> So it seems to me the gcc-6.4.0-r1 much more resource hungry or there is
> a bug in it.

I have a similar system, but Atom N270. I wouldn't want to compile much on it, 
and certainly not GCC. I NFS-export its $PORTDIR to this much more powerful 
box, do the emerging here and then just install packages on the Atom. Still 
not exactly fast, but incomparably better.

-- 
Regards
Peter

Re: [gentoo-user] [SOLVED] gcc-6.4.0-r1::gentoo failed (compile phase)

[thelma]

On 03/28/2018 01:32 AM, Peter Humphrey wrote:
> On Tuesday, 27 March 2018 16:25:10 BST thelma@sys-concept.com wrote:
>> SOLVED!
>> The gcc-6.4.0-r1 compiled with
>> MAKEOPTS="-j1"
>>
>> What is strange is that this is the second low profile system that
>> gcc-6.4.0-r1 failed to compile large package. My other boxed was 4-core
>> and 4GB of RAM and I had to switch to MAKEOPTS="-j1"
>>
>> The above system is: Intel(R) Atom(TM) CPU 330 @ 1.60GHz with 2GB of RAM
>> and "gcc-4.9.4" compiled "gcc-6.4.0-r1" with MAKEOPTS="-j5" OK
>> but when I switched/upgrade profile to "gcc-6.4.0-r1" it filed to
>> compile gcc-6.4.0 with MAKEOPTS="-j5"
>> I had lower MAKEOPTS to -j1
>>
>> So it seems to me the gcc-6.4.0-r1 much more resource hungry or there is
>> a bug in it.
> 
> I have a similar system, but Atom N270. I wouldn't want to compile much on it, 
> and certainly not GCC. I NFS-export its $PORTDIR to this much more powerful 
> box, do the emerging here and then just install packages on the Atom. Still 
> not exactly fast, but incomparably better.

I should have done it as well, it is a bit too late I have only
45-packages left to compile out of 710.
Is it better use NFS or distcc?
Do you have a good link how to do it with: "NFS-export  $PORTDIR"

--
Thelma

Re: [gentoo-user] [SOLVED] gcc-6.4.0-r1::gentoo failed (compile phase)

[Peter Humphrey]

On Wednesday, 28 March 2018 16:14:49 BST thelma@sys-concept.com wrote:
> On 03/28/2018 01:32 AM, Peter Humphrey wrote:
[...]
> > I have a similar system, but Atom N270. I wouldn't want to compile much on
> > it, and certainly not GCC. I NFS-export its $PORTDIR to this much more
> > powerful box, do the emerging here and then just install packages on the
> > Atom. Still not exactly fast, but incomparably better.
> 
> I should have done it as well, it is a bit too late I have only
> 45-packages left to compile out of 710.
> Is it better use NFS or distcc?
> Do you have a good link how to do it with: "NFS-export  $PORTDIR"

I think NFS may be simpler to operate, but that may be because I'm more
familiar with it. You just need something like this in the Atom's /etc/
exports: /usr/portage 192.168.1.5(rw,no_subtree_check,anonuid=250,anongid=250,no_wdelay)

That IP address is the big beast host, and of course 250 is the portage user.

I don't know of a guide on the web, but basically, the method is to construct
a 32-bit chroot on your host system and install a mirror of your Atom system
in it. Copy your Atom's /etc/portage directory into the chroot and adjust
things like --jobs to suit the chroot host, but make sure all the USE flags
are the same as on the Atom. It'll take an hour or two to build the system,
but you only have to do it once, and of course it'll be done at the speed of
your host machine. You don't need to keep running etc-update or equivalent;
just build the binaries.

My chroot is /mnt/atom and this script starts it ready to chroot into:

$ 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 -t tmpfs tmpfs -o noatime,nosuid,nodev,noexec,mode=1777 /mnt/atom/tmp
    mount -t tmpfs tmpfs -o noatime,uid=portage,gid=portage,mode=0775 /mnt/atom/var/tmp/portage
    mount -t nfs -o vers=3 192.168.1.2:/usr/portage /mnt/atom/usr/portage
    rm -f /mnt/atom/etc/mtab
    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
    ln -s /proc/self/mounts /mnt/atom/etc/mtab
    umount -R /mnt/atom
    mount /mnt/atom
}

You may prefer not to bother with tmpfs, but I have 32GB RAM on my host, so
it's efficient here. That IP address is the Atom machine.

No doubt someone more skilled than me at bash scripting could improve on my
script; suggestions welcome.

After updating the chroot you can emerge -k or -K on your Atom machine, after
syncing which will now be the most time-consuming part of the operation.

Let me know if anything isn't clear.

Thanks to Neil Bothwick, who showed me how to do this several years ago.

-- 
Regards
Peter

Re: [gentoo-user] [SOLVED] gcc-6.4.0-r1::gentoo failed (compile phase)

[thelma]

On 03/28/2018 10:40 AM, Peter Humphrey wrote:
> On Wednesday, 28 March 2018 16:14:49 BST thelma@sys-concept.com wrote:
>> On 03/28/2018 01:32 AM, Peter Humphrey wrote:
> [...]
>>> I have a similar system, but Atom N270. I wouldn't want to compile much on
>>> it, and certainly not GCC. I NFS-export its $PORTDIR to this much more
>>> powerful box, do the emerging here and then just install packages on the
>>> Atom. Still not exactly fast, but incomparably better.
>>
>> I should have done it as well, it is a bit too late I have only
>> 45-packages left to compile out of 710.
>> Is it better use NFS or distcc?
>> Do you have a good link how to do it with: "NFS-export  $PORTDIR"
> 
> I think NFS may be simpler to operate, but that may be because I'm more
> familiar with it. You just need something like this in the Atom's /etc/
> exports: /usr/portage 192.168.1.5(rw,no_subtree_check,anonuid=250,anongid=250,no_wdelay)
> 
> That IP address is the big beast host, and of course 250 is the portage user.
> 
> I don't know of a guide on the web, but basically, the method is to construct
> a 32-bit chroot on your host system and install a mirror of your Atom system
> in it. Copy your Atom's /etc/portage directory into the chroot and adjust
> things like --jobs to suit the chroot host, but make sure all the USE flags
> are the same as on the Atom. It'll take an hour or two to build the system,
> but you only have to do it once, and of course it'll be done at the speed of
> your host machine. You don't need to keep running etc-update or equivalent;
> just build the binaries.
> 
> My chroot is /mnt/atom and this script starts it ready to chroot into:
> 
> $ 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 -t tmpfs tmpfs -o noatime,nosuid,nodev,noexec,mode=1777 /mnt/atom/tmp
>     mount -t tmpfs tmpfs -o noatime,uid=portage,gid=portage,mode=0775 /mnt/atom/var/tmp/portage
>     mount -t nfs -o vers=3 192.168.1.2:/usr/portage /mnt/atom/usr/portage
>     rm -f /mnt/atom/etc/mtab
>     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
>     ln -s /proc/self/mounts /mnt/atom/etc/mtab
>     umount -R /mnt/atom
>     mount /mnt/atom
> }
> 
> You may prefer not to bother with tmpfs, but I have 32GB RAM on my host, so
> it's efficient here. That IP address is the Atom machine.
> 
> No doubt someone more skilled than me at bash scripting could improve on my
> script; suggestions welcome.
> 
> After updating the chroot you can emerge -k or -K on your Atom machine, after
> syncing which will now be the most time-consuming part of the operation.
> 
> Let me know if anything isn't clear.
> 
> Thanks to Neil Bothwick, who showed me how to do this several years ago.

I will try do it but I'm trying to decipher the code your wrote :-)
My atom-330 is 64-bit.
I think your approach was discussed in this forum topic:
https://forums.gentoo.org/viewtopic-p-6817608.html#6817608

-------copy------------
#!/bin/sh

HOST=${0##*/}
HOST=${HOST#*-}

mkdir -p --mode=0755 /mnt/${HOST}

mount -t nfs -o rw,intr,noatime,actimeo=60,vers=4,fsc ${HOST}:/ /mnt/${HOST}
mount --bind /dev /mnt/${HOST}/dev
mount --bind /dev/shm /mnt/${HOST}/dev/shm
mount --bind /proc /mnt/${HOST}/proc
mount --bind /sys /mnt/${HOST}/sys
mount --bind /usr/portage /mnt/${HOST}/usr/portage
mount --bind /usr/local/portage /mnt/${HOST}/usr/local/portage
mount --bind /var/tmp/portage /mnt/${HOST}/var/tmp/portage

env -i - HOME="/root" TERM="$TERM" chroot /mnt/${HOST} /bin/bash -l

umount /mnt/${HOST}/dev/shm
umount /mnt/${HOST}/dev
umount /mnt/${HOST}/proc
umount /mnt/${HOST}/sys
umount /mnt/${HOST}/usr/portage
umount /mnt/${HOST}/usr/local/portage
umount /mnt/${HOST}/var/tmp/portage
umount /mnt/${HOST}
------end copy--------------

In the link above I think the Moderator suggested the change:
...
mkdr /var/tmp/portage/$HOST
mount --bind /var/tmp/portage/$HOST /mnt/${HOST}/var/tmp/portage
---

I'm still searching for a good guid howto over NFS.
It is till not clear to me what to do before or after.  I need to start
with emerging NFS :-/

On my Atom-330 with MAKEOPTS="-j1" it took me over 12-hours to compile
just gcc-6.4.0-r1 :-/
and I have server on that network 8-core AMD with 32-GB or RAM (so I
might as well put it into a good use).

--
Thelma

[gentoo-user] Re: gcc-6.4.0-r1::gentoo failed (compile phase)

[Ian Zimmerman]

On 2018-03-28 17:40, Peter Humphrey wrote:

> I think NFS may be simpler to operate, but that may be because I'm
> more familiar with it. You just need something like this in the Atom's
> /etc/ exports: /usr/portage
> 192.168.1.5(rw,no_subtree_check,anonuid=250,anongid=250,no_wdelay)

NBD (Network Block Device) may be an alternative to NFS in some situations.

I now use it for /var/tmp/portage on my storage-poor machine.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

Re: [gentoo-user] [SOLVED] gcc-6.4.0-r1::gentoo failed (compile phase)

[thelma]

On 03/28/2018 12:08 PM, thelma@sys-concept.com wrote:
> On 03/28/2018 10:40 AM, Peter Humphrey wrote:
>> On Wednesday, 28 March 2018 16:14:49 BST thelma@sys-concept.com wrote:
>>> On 03/28/2018 01:32 AM, Peter Humphrey wrote:
>> [...]
>>>> I have a similar system, but Atom N270. I wouldn't want to compile much on
>>>> it, and certainly not GCC. I NFS-export its $PORTDIR to this much more
>>>> powerful box, do the emerging here and then just install packages on the
>>>> Atom. Still not exactly fast, but incomparably better.
>>>
>>> I should have done it as well, it is a bit too late I have only
>>> 45-packages left to compile out of 710.
>>> Is it better use NFS or distcc?
>>> Do you have a good link how to do it with: "NFS-export  $PORTDIR"
>>
>> I think NFS may be simpler to operate, but that may be because I'm more
>> familiar with it. You just need something like this in the Atom's /etc/
>> exports: /usr/portage 192.168.1.5(rw,no_subtree_check,anonuid=250,anongid=250,no_wdelay)
>>
>> That IP address is the big beast host, and of course 250 is the portage user.
>>
>> I don't know of a guide on the web, but basically, the method is to construct
>> a 32-bit chroot on your host system and install a mirror of your Atom system
>> in it. Copy your Atom's /etc/portage directory into the chroot and adjust
>> things like --jobs to suit the chroot host, but make sure all the USE flags
>> are the same as on the Atom. It'll take an hour or two to build the system,
>> but you only have to do it once, and of course it'll be done at the speed of
>> your host machine. You don't need to keep running etc-update or equivalent;
>> just build the binaries.
>>
>> My chroot is /mnt/atom and this script starts it ready to chroot into:
>>
>> $ 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 -t tmpfs tmpfs -o noatime,nosuid,nodev,noexec,mode=1777 /mnt/atom/tmp
>>     mount -t tmpfs tmpfs -o noatime,uid=portage,gid=portage,mode=0775 /mnt/atom/var/tmp/portage
>>     mount -t nfs -o vers=3 192.168.1.2:/usr/portage /mnt/atom/usr/portage
>>     rm -f /mnt/atom/etc/mtab
>>     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
>>     ln -s /proc/self/mounts /mnt/atom/etc/mtab
>>     umount -R /mnt/atom
>>     mount /mnt/atom
>> }
>>
>> You may prefer not to bother with tmpfs, but I have 32GB RAM on my host, so
>> it's efficient here. That IP address is the Atom machine.
>>
>> No doubt someone more skilled than me at bash scripting could improve on my
>> script; suggestions welcome.
>>
>> After updating the chroot you can emerge -k or -K on your Atom machine, after
>> syncing which will now be the most time-consuming part of the operation.
>>
>> Let me know if anything isn't clear.
>>
>> Thanks to Neil Bothwick, who showed me how to do this several years ago.
> 
> I will try do it but I'm trying to decipher the code your wrote :-)
> My atom-330 is 64-bit.
> I think your approach was discussed in this forum topic:
> https://forums.gentoo.org/viewtopic-p-6817608.html#6817608
> 
> -------copy------------
> #!/bin/sh
> 
> HOST=${0##*/}
> HOST=${HOST#*-}
> 
> mkdir -p --mode=0755 /mnt/${HOST}
> 
> mount -t nfs -o rw,intr,noatime,actimeo=60,vers=4,fsc ${HOST}:/ /mnt/${HOST}
> mount --bind /dev /mnt/${HOST}/dev
> mount --bind /dev/shm /mnt/${HOST}/dev/shm
> mount --bind /proc /mnt/${HOST}/proc
> mount --bind /sys /mnt/${HOST}/sys
> mount --bind /usr/portage /mnt/${HOST}/usr/portage
> mount --bind /usr/local/portage /mnt/${HOST}/usr/local/portage
> mount --bind /var/tmp/portage /mnt/${HOST}/var/tmp/portage
> 
> env -i - HOME="/root" TERM="$TERM" chroot /mnt/${HOST} /bin/bash -l
> 
> umount /mnt/${HOST}/dev/shm
> umount /mnt/${HOST}/dev
> umount /mnt/${HOST}/proc
> umount /mnt/${HOST}/sys
> umount /mnt/${HOST}/usr/portage
> umount /mnt/${HOST}/usr/local/portage
> umount /mnt/${HOST}/var/tmp/portage
> umount /mnt/${HOST}
> ------end copy--------------

Can anybody explain what these two line do in the above script?
HOST=${0##*/}
HOST=${HOST#*-}

--
Thelma

Re: [gentoo-user] Re: gcc-6.4.0-r1::gentoo failed (compile phase)

[Grant Taylor]

On 03/28/2018 02:51 PM, Ian Zimmerman wrote:
> NBD (Network Block Device) may be an alternative to NFS in some situations.

Doesn't NBD (iSCSI and ATA over Ethernet) show up more like SAN compared 
to NFS which is NAS?



-- 
Grant. . . .
unix || die

[gentoo-user] Re: gcc-6.4.0-r1::gentoo failed (compile phase)

[Ian Zimmerman]

On 2018-03-28 15:08, Grant Taylor wrote:

> Doesn't NBD (iSCSI and ATA over Ethernet) show up more like SAN
> compared to NFS which is NAS?

Well, that's too many 3-letter acronyms for me ;-)  It is lower level,
yes.  All the filesystem code is on the client; the server only handles
requests of the form "here's the new contents of block 1234, and be sure
to tell me when it's safely on disk".

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

Re: [gentoo-user] Re: gcc-6.4.0-r1::gentoo failed (compile phase)

[Grant Taylor]

On 03/28/2018 03:53 PM, Ian Zimmerman wrote:
> Well, that's too many 3-letter acronyms for me   It is lower level, yes. 
> All the filesystem code is on the client; the server only handles requests 
> of the form "here's the new contents of block 1234, and be sure to tell 
> me when it's safely on disk".

Fair enough.

The point being, NBD / AoE / iSCSI are SAN technologies and not 
conducive for multiple clients to access at the same time (without a 
clustered file system).  Unlike NFS which is safe for multiple clients 
to access at the same time.  So, having multiple distributed build 
machines sort of necessitates NFS (or a clustered file system).



-- 
Grant. . . .
unix || die

[gentoo-user] Re: gcc-6.4.0-r1::gentoo failed (compile phase)

[Ian Zimmerman]

On 2018-03-28 16:09, Grant Taylor wrote:

> The point being, NBD / AoE / iSCSI are SAN technologies and not
> conducive for multiple clients to access at the same time (without a
> clustered file system).  Unlike NFS which is safe for multiple clients
> to access at the same time.  So, having multiple distributed build
> machines sort of necessitates NFS (or a clustered file system).

That's quite true.  As I wrote, in my case the build is not distributed,
just the storage; and the server has enough storage for me to dedicate
another part of it to serve as a remote device for another client,
should it be needed.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

Re: [gentoo-user] [SOLVED] gcc-6.4.0-r1::gentoo failed (compile phase)

[J García]

2018-03-28 12:08 GMT-06:00  <thelma@sys-concept.com>:

> I'm still searching for a good guid howto over NFS.
> It is till not clear to me what to do before or after.  I need to start
> with emerging NFS :-/
>
> On my Atom-330 with MAKEOPTS="-j1" it took me over 12-hours to compile
> just gcc-6.4.0-r1 :-/
> and I have server on that network 8-core AMD with 32-GB or RAM (so I
> might as well put it into a good use).
I would not bother with NFS for this, portage has some options you can
add to make.conf to transfer the binary packages using HTTP, namely
FEATURES=getbinpkg and the variable PORTAGE_BINHOST, you can add those
to the less powerful machine, check the manual about make.conf for the
details on each.
An example:
PORTAGE_BINHOST="http://10.0.0.X:8000"
Just make it appropriate for your LAN, then run a simple HTTP server
on the directory that contains the binary packages on the powerful
machine, no need install any HTTP server package, python can do it
[1][2]:
For example:
$ cd $PKGDIR
$ python2 -m SimpleHTTPServer 8000
or
$ python3 -m http.server 8000
You can even add that as part of the service that creates the chroot
as suggested before.
.
[1] https://docs.python.org/3.6/library/http.server.html?highlight=httpserver#module-http.server
[2] https://docs.python.org/2/library/simplehttpserver.html#module-SimpleHTTPServer