building m4 in poudriere cross-build

[Paul Mather]

On Dec 14, 2016, at 4:58 PM, Ian Lepore <ian at freebsd.org> wrote:

> On Wed, 2016-12-14 at 10:01 -0500, Paul Mather wrote:
>> 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.
> 
> I have successfully crossbuilt m4 using poudriere and qemu-static on
> freebsd 11, but I haven't tried in the past 6-8 months.  Something
> might have changed in the m4 port, like their configure script might be
> doing a stack overflow check now that it never used to do.  I could see
> a stack overflow test taking a long time under qemu, but 24 hours seems
> a bit much.


The last time I was able successfully to cross-build m4 is on 2016-11-06.  Since then, I think it has failed to get past the configure stage and Poudriere times out.

As you surmise, the last thing it does in the configure script is check for stack overflow:

=====
[[...]]
checking for features.h... no
checking for wctype.h... (cached) yes
checking for dirent.h... (cached) yes
checking for inttypes.h... (cached) yes
checking for working C stack overflow detection...
=====

It gets hung up on that until Poudriere times out or you CTRL-C the build job.

The m4 package is just one example.  In the past they have built and then something happens and then they don't (math/gmp is another example like this).  Some (like net/norm) I don't recall ever having managed to cross-build.

I was very surprised when I moved the FreeBSD/arm Poudriere building to an actual Raspberry Pi and everything built fine first time.  I don't build many packages for my FreeBSD/arm systems, so it doesn't actually take too long for me (building the jail takes longer:).

Cheers,

Paul.