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

[J García]

2018-03-28 12:08 GMT-06:00  :

> 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

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

[thelma]

On 03/28/2018 12:08 PM, the...@sys-concept.com wrote:
> On 03/28/2018 10:40 AM, Peter Humphrey wrote:
>> On Wednesday, 28 March 2018 16:14:49 BST the...@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] [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 the...@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

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

[Peter Humphrey]

On Wednesday, 28 March 2018 16:14:49 BST the...@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 01:32 AM, Peter Humphrey wrote:
> On Tuesday, 27 March 2018 16:25:10 BST the...@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 Tuesday, 27 March 2018 16:25:10 BST the...@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/27/2018 03:19 AM, Helmut Jarausch wrote:
> On 03/26/2018 01:30:19 PM, the...@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