Date: Wed, 14 Dec 2016 17:31:00 -0500 From: Paul Mather <paul@gromit.dlib.vt.edu> To: Ian Lepore <ian@freebsd.org> Cc: Vick Khera <vivek@khera.org>, freebsd-arm@freebsd.org Subject: Re: building m4 in poudriere cross-build Message-ID: <144A0FFB-730E-42C4-8FE6-7387505145A0@gromit.dlib.vt.edu> In-Reply-To: <1481752684.1889.425.camel@freebsd.org> References: <CALd%2Bdcere=CVXCAp=Aa98gEK%2BUyzQAFq_ke%2BcokgLbv=WGO2vA@mail.gmail.com> <706A6D47-21F3-4017-8CD4-C651F37900E6@gromit.dlib.vt.edu> <1481752684.1889.425.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 14, 2016, at 4:58 PM, Ian Lepore <ian@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@khera.org> wrote: >>=20 >>>=20 >>> 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. >>>=20 >>> The logs show this: >>>=20 >>> 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 >>>=20 >>> The build machine is: FreeBSD 11.0-RELEASE-p5/amd64 with Poudriere >>> 3.1.14 >>>=20 >>> The build jail target is 11.0-RELEASE-p5/armv6 freshly updated. >>>=20 >>> 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? >>=20 >> 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. >>=20 >> 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. :-) >>=20 >> 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. >>=20 >> 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. >>=20 >> Cheers, >>=20 >> Paul. >=20 > 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: =3D=3D=3D=3D=3D [[...]] 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... =3D=3D=3D=3D=3D 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?144A0FFB-730E-42C4-8FE6-7387505145A0>