From owner-freebsd-arm@freebsd.org Wed Dec 14 22:31:03 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5F9B5C80AD0 for ; Wed, 14 Dec 2016 22:31:03 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 329611ABF; Wed, 14 Dec 2016 22:31:02 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from [172.27.0.245] (unknown [172.27.0.245]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 28BEF247; Wed, 14 Dec 2016 17:31:01 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: building m4 in poudriere cross-build From: Paul Mather In-Reply-To: <1481752684.1889.425.camel@freebsd.org> Date: Wed, 14 Dec 2016 17:31:00 -0500 Cc: Vick Khera , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <144A0FFB-730E-42C4-8FE6-7387505145A0@gromit.dlib.vt.edu> References: <706A6D47-21F3-4017-8CD4-C651F37900E6@gromit.dlib.vt.edu> <1481752684.1889.425.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 22:31:03 -0000 On Dec 14, 2016, at 4:58 PM, Ian Lepore wrote: > On Wed, 2016-12-14 at 10:01 -0500, Paul Mather wrote: >> On Dec 14, 2016, at 9:42 AM, Vick Khera 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.