From owner-freebsd-arm@freebsd.org Wed Dec 14 15:01:09 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 71539C80223 for ; Wed, 14 Dec 2016 15:01:09 +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 51A9AC35 for ; Wed, 14 Dec 2016 15:01:09 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from [128.173.38.82] (unknown [128.173.38.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id A47AF1B8; Wed, 14 Dec 2016 10:01:02 -0500 (EST) Content-Type: text/plain; charset=us-ascii 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: Date: Wed, 14 Dec 2016 10:01:01 -0500 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <706A6D47-21F3-4017-8CD4-C651F37900E6@gromit.dlib.vt.edu> References: To: Vick Khera 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 15:01:09 -0000 On Dec 14, 2016, at 9:42 AM, Vick Khera 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. >=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? 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.