Using poudriere (with -a arm.armv6 -x ) on amd64 vs. building lang/gcc6: Some notes from my first attempts

[Mark Millard]

On 2017-Jan-18, at 2:33 PM, diffusae <punasipuli at t-online.de> wrote:

> On 18.01.2017 23:13, Mark Millard wrote:
>>> Stop.
>>> make: stopped in /usr/ports/lang/gcc6
>> from running out of swap space.
> 
> I've had the same with lang/gcc.
> After upgrading to the lastest emulators/qemu-user-static, it takes
> quite a long time, but it will compile and finished.

Thanks for the note.

But. . .

My installation is from ports head -r431413 and
https://svnweb.freebsd.org/ports/head/emulators/
shows qemu-user-static and qemu-sbruno have not
changed since:

qemu-sbruno/	         431215	 7 days

qemu-user-static/	 415498	 8 months

(user-static is a slave port off of sbruno)

# svnlite info /usr/ports/ | grep "Re[plv]"
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 431413
Last Changed Rev: 431413

# pkg info qemu-user-static
qemu-user-static-2.8.50.g20161228_1
Name           : qemu-user-static
Version        : 2.8.50.g20161228_1
Installed on   : Sun Jan 15 13:39:14 2017 PST
Origin         : emulators/qemu-user-static
Architecture   : freebsd:12:x86:64
Prefix         : /usr/local
Categories     : emulators
Licenses       : GPLv2
Maintainer     : sbruno at FreeBSD.org
WWW            : http://wiki.qemu.org/Main_Page
Comment        : QEMU CPU Emulator github bsd-user branch - static user targets
Annotations    :
Flat size      : 112MiB

lang/gcc6 is a much bigger build than lang/gcc49 (or lang/gcc)
from what I can tell (full bootstrap). I'd noticed that on
various native builds (armv6, powerpc64, amd64).

poudriere and the rest of the installed were also from
-r431413 .

> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214944

This predates what I was using and so is not a "fix"
for what I observed with the memory and swap that I
provided.

I had deliberately picked the port that I build that
I thought would use the most time and RAM/swap.

I've not done anything that would indicate if more memory
leaks are involved or not. If there are I'd expect that
the leak rate was slow since it ran for over 72 hours
and made sustained progress right up to where it failed
from what I can tell.

===
Mark Millard
markmi at dsl-only.net