Date: Thu, 15 Dec 2016 09:16:54 -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: <5A18CCF9-E84E-46C1-9575-720598C8580F@gromit.dlib.vt.edu> In-Reply-To: <1481755164.1889.430.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> <144A0FFB-730E-42C4-8FE6-7387505145A0@gromit.dlib.vt.edu> <1481755164.1889.430.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >>=20 >>>=20 >>> On Wed, 2016-12-14 at 10:01 -0500, Paul Mather wrote: >>>>=20 >>>> On Dec 14, 2016, at 9:42 AM, Vick Khera <vivek@khera.org> wrote: >>>>=20 >>>>>=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? >>>> 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. >>> 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. >>=20 >> 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. >>=20 >> As you surmise, the last thing it does in the configure script is >> check for stack overflow: >>=20 >> =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 >>=20 >> It gets hung up on that until Poudriere times out or you CTRL-C the >> build job. >>=20 >> 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. >>=20 >> 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:). >>=20 >> Cheers, >>=20 >> Paul. >=20 > Hmm, looks like nothing has changed in the m4 port for at least 8 > months. What has changed since November 6 is clang. >=20 > 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, Paul.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5A18CCF9-E84E-46C1-9575-720598C8580F>