Date: Thu, 15 Dec 2016 09:07: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: <1481818044.1972.6.camel@freebsd.org> In-Reply-To: <5A18CCF9-E84E-46C1-9575-720598C8580F@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> <1481755164.1889.430.camel@freebsd.org> <5A18CCF9-E84E-46C1-9575-720598C8580F@gromit.dlib.vt.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2016-12-15 at 09:16 -0500, Paul Mather wrote: > On Dec 14, 2016, at 5:39 PM, Ian Lepore <ian@freebsd.org> wrote: > > > > > 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. > > That is true, but in the case of the example ports mentioned above > they don't fail to compile on arm---they just fail to compile on arm > via the QEMU arm emulator. That suggests to me that it's not so much > that certain ports are broken but that maybe clang is generating code > that the QEMU emulator chokes on whereas a real arm processor that > FreeBSD supports is fine. > > It seems to me that it is the QEMU emulator that may need fixing, not > individual ports. > > Cheers, It sounds like that's true (qemu is broken) in this case, but in general there are many ports that fail to build or crossbuild on arm that need only small changes to work. On the other hand, there are some that will never work right because we've made some bad choices, such as claiming that armv6 and armv7 are basically the same thing. The ports contain #ifdef stuff that makes assumptions like "armv6 can never be multicore so I don't need to do memory barrier operations". -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1481818044.1972.6.camel>