building m4 in poudriere cross-build

[Paul Mather]

On Dec 14, 2016, at 9:42 AM, Vick Khera <vivek at khera.org> wrote:

> I have a poudriere cross-building configuration set up on a Xeon running
> FreebSD 11.0. The jail was set up with the "-x" option to use the native
> cross-build tools. This has worked really well for a while, but today I am
> trying to update the packages for my raspberry pi 2, and poudriere just
> kind of sits there in the configure step when building m4 (as a dependency
> trying to build subversion). I haven't built this set of packages in over a
> month.
> 
> The logs show this:
> 
> checking for dirent.h... (cached) yes
> checking for inttypes.h... (cached) yes
> checking for working C stack overflow detection... make: Working in:
> /usr/ports/devel/m4
> make: Working in: /usr/ports/devel/m4
> make: Working in: /usr/ports/devel/m4
> make: Working in: /usr/ports/devel/m4
> make: Working in: /usr/ports/devel/m4
> make: Working in: /usr/ports/devel/m4
> make: Working in: /usr/ports/devel/m4
> make: Working in: /usr/ports/devel/m4
> make: Working in: /usr/ports/devel/m4
> make: Working in: /usr/ports/devel/m4
> make: Working in: /usr/ports/devel/m4
> make: Working in: /usr/ports/devel/m4
> 
> The build machine is: FreeBSD 11.0-RELEASE-p5/amd64 with Poudriere 3.1.14
> 
> The build jail target is 11.0-RELEASE-p5/armv6 freshly updated.
> 
> I let this run for over 18 hours, and it just kept repeating that last
> line. Has anyone had success with this set up recently? Maybe the
> qemu-arm-static is not working right now?


I had (have) the same problem.  Not only would packages like m4 just grind away for hours on end doing nothing until Poudriere timed out the build (after 24 hours), but other packages I use like math/gmp  and net/norm would fail to build with various errors.  I use Saltstack and so these kind of failures meant that sysutils/py-salt would be skipped for building, meaning it fell behind that of the other architectures I was running.

In the end, I decided to simply set up Poudriere on my FreeBSD/arm Raspberry Pi 2 system and build packages there instead.  Running natively, all these packages build correctly and once again I am able to have up-to-date packages on my FreeBSD/arm systems.  Package building isn't as fast as on my cross-build FreeBSD/amd64 system, but at least they actually build---slower is better than never. :-)

I can only assume that the QEMU arm emulator is deficient compared to an actual CPU on a running FreeBSD/arm system.  If the official FreeBSD/arm package repository is built via a cross-built environment using QEMU, I presume these problems will linger until QEMU works properly.

I also assume that maybe the FreeBSD/arm package builders are consider these ports simply to be broken on FreeBSD/arm, which is why they fail to build under QEMU, when in fact the packages do actually build on an actual FreeBSD/arm system.  At least that has been my experience for the last few months.

Cheers,

Paul.