Date: Wed, 14 Dec 2016 15:39:24 -0700 From: Ian Lepore <ian@freebsd.org> To: Paul Mather <paul@gromit.dlib.vt.edu> Cc: Vick Khera <vivek@khera.org>, freebsd-arm@freebsd.org Subject: Re: building m4 in poudriere cross-build Message-ID: <1481755164.1889.430.camel@freebsd.org> In-Reply-To: <144A0FFB-730E-42C4-8FE6-7387505145A0@gromit.dlib.vt.edu> 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> <144A0FFB-730E-42C4-8FE6-7387505145A0@gromit.dlib.vt.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2016-12-14 at 17:31 -0500, Paul Mather wrote: > 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: > > > > > > > > > > > > > > > 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. Hmm, looks like nothing has changed in the m4 port for at least 8 months. What has changed since November 6 is clang. There are many ports that fail to compile on arm that need only a tiny change to start working (for either native or cross-compile). It doesn't take long to figure out the fixes, but it's virtually impossible to get the fixes committed. The ports maintainers often don't know anything about arm or other platforms and are reluctant to commit changes they don't understand and can't test. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1481755164.1889.430.camel>