Date: Tue, 15 Dec 2015 10:22:05 -0600 From: Karl Denninger <karl@denninger.net> To: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Updating / keeping current strategies? Message-ID: <56703E2D.8050504@denninger.net> In-Reply-To: <1450195123.25138.42.camel@freebsd.org> References: <5666F37C.4060908@denninger.net> <10BBDDBB-75AA-4034-B494-9EB28D009882@gromit.dlib.vt.edu> <566EEAC4.1060306@denninger.net> <566F0238.9060605@denninger.net> <1450190791.25138.30.camel@freebsd.org> <567031C9.2090109@denninger.net> <1450195123.25138.42.camel@freebsd.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On 12/15/2015 09:58, Ian Lepore wrote: > On Tue, 2015-12-15 at 09:29 -0600, Karl Denninger wrote: >> On 12/15/2015 08:46, Ian Lepore wrote: >>>>> There seem to be some problems with this in the general sense, >>>>> unless >>>>> you're willing to move the media around (I'm generally not.) >>>>> >>>>> Using that script in the Wiki appears to work, but there are >>>>> problems. >>>>> If you try to nfs mount the object and source directories on >>>>> the >>>>> target >>>>> so you can do a "make installworld" or "make installkernel" on >>>>> the >>>>> target you quickly find that clang wasn't cross-built in the >>>>> object >>>>> directory; the "tmp" directory in object contains a copy of it, >>>>> but >>>>> it's >>>>> compiled for your _*source*_ machine (in this case >>>>> FreeBSD/amd64) >>>>> and >>>>> the install blows up as it can't determine the cc version. The >>>>> interesting thing is that what's in ~/nfsroot/usr/bin/cc is >>>>> correct >>>>> which doesn't appear to make sense, but it is what it is. >>>>> >>>>> I'm going to see if I can get a rsync-type thing to work.... >>>>> >>>> It.... gets.... worse. >>>> >>>> I can update using rsync. However, the armv6hf target given in >>>> the >>>> wiki >>>> at https://wiki.freebsd.org/FreeBSD/arm/crossbuild produces >>>> binaries >>>> that blow up when floating point is attempted. Armv6 is >>>> deprecated >>>> and >>>> won't build at all. >>>> >>> I'm having a hard time understanding this. Nobody else is >>> reporting >>> problems with cross-built binaries that use floating point. Also, >>> armv6 is deprecated only in the sense that armv6hf is more >>> efficient >>> and there's no reason to use the old softfp ABI anymore. But that >>> doesn't mean it can't be built, it builds and cross-builds just >>> fine. >>> >>> -- Ian >> Well, I'm reporting what I got. I followed the instructions in the >> Wiki, got a product nfsroot directory and the expected src and obj >> directories, attempted to mount the src and obj directories over nfs >> and >> execute a "make installworld" on the target and that blew up with >> complaints about expected directories being missing. >> > Oh, you can't do that. The pathnames in the obj directory are correct > for the build machine, but wrong when nfs-mounted on another machine. Well, but they are if I maintain the paths. Example: I have the build at /pics/CrossBuild on the source (10.2-STABLE amd64) machine. I export /pics/CrossBuild. I then mount that at /pics/CrossBuild on the target. Now the paths are the same. But..... when I try to do a "make installkernel" as you would do if doing this on a consistent architecture what I get is this: root@Pool-MCP:/pics/CrossBuild # ./mk installkernel TARGET_ARCH=armv6hf + cd /pics/CrossBuild/src + nice -10 make -j 4 -DNO_CLEAN 'TARGET_ARCH=armv6hf' 'DESTDIR=/pics/CrossBuild/nfsroot' '__MAKE_CONF=/pics/CrossBuild/config/make.conf' 'srcconf=/pics/CrossBuild/config/src.conf' 'KERNCONF=RPI2' 'UBLDR_LOADADDR=0x2000000' installkernel 'TARGET_ARCH=armv6hf' --- installkernel --- --- installkernel --- -------------------------------------------------------------- >>> Installing kernel RPI2 -------------------------------------------------------------- cd /pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/sys/RPI2; MAKEOBJDIRPREFIX=/pics/CrossBuild/obj/arm.armv6hf MACHINE_ARCH=armv6hf MACHINE=arm CPUTYPE= GROFF_BIN_PATH=/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/tmp/legacy/usr/share/tmac CC="cc " CXX="c++ " DEPFLAGS="" CPP="cpp " AS="as" AR="ar" LD="ld" NM=nm OBJDUMP=objdump OBJCOPY="objcopy" RANLIB=ranlib STRINGS= SIZE="size" PATH=/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/tmp/legacy/usr/sbin:/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/tmp/legacy/usr/bin:/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/tmp/legacy/bin:/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/tmp/usr/sbin:/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin make KERNEL=kernel install sh: cc: Exec format error make[2]: "/pics/CrossBuild/src/share/mk/bsd.compiler.mk" line 137: Unable to determine compiler type for cc . Consider setting COMPILER_TYPE. *** [installkernel] Error code 1 make[1]: stopped in /pics/CrossBuild/src 1 error make[1]: stopped in /pics/CrossBuild/src *** [installkernel] Error code 2 make: stopped in /pics/CrossBuild/src 1 error make: stopped in /pics/CrossBuild/src root@Pool-MCP:/pics/CrossBuild # When investigating this what I find is that the executable in the path for "cc" is in fact an arm64 executable! So I have a built system but no way to install it. > > The instructions in the wiki page you cited are how to set up a > development environment that uses an nfs-mounted root directory. You > can also use it as a source for rsync, but you can't install directly > from the objdir of such a build environment using an nfs mount unless > the target system has the exact directory layout of the build system > after nfs-mounting the source and obj dirs. Except that doesn't work because the PATH contains executables for the source which is a different architecture. And when I tried to rsync it I got a system that booted and ran, sort of, but anything that did floating point blew up. That might be because of schg flags prevented some of the copies and rsync has no good way to get around that (removing them from the target is undesirable for all the obvious reasons.) > > Another way to make it work is to nfs-mount the target's root directory > on your build machine, then you can make installworld DESTDIR=<mountpt> That's an interesting idea that I will look into. It's undesirable for a number of reasons down the road (enabling nfs server on these machines isn't my idea of a good thing over time) but it might get me going for the moment. >> I then attempted to rsync the nfsroot directory to the target machine >> (a >> Raspberry Pi2); that succeeded. But, once the machine was rebooted >> any >> attempt to execute anything that had floating point operations >> dumped; >> "awk", for example, blows up. >> > I built on a 10.2-STABLE machine, if that matters. > Using a kernel and world built yesterday for armv6hf... > > root@wand :~ # awk "BEGIN {print 2.7+4.2 }" > 6.9 > > I do all my building on a 10-stable machine. > > I wonder if your first attempt to installworld somehow installed some > x86 stuff by accident and now you've got a mixed/broken world, and rsyn > c didn't fix it because some of the broken files were more recent? > > -- Ian Maybe. But I don't think so; I suspect the issue revolves around schg flags (in other words some things didn't update) and if so it's a problem since I don't believe rsync can deal with that. -- Karl Denninger karl@denninger.net <mailto:karl@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ [-- Attachment #2 --] 0 *H 010 `He 0 *H _0[0C)0 *H 01 0 UUS10UFlorida10U Niceville10U Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H Cuda Systems LLC CA0 150421022159Z 200419022159Z0Z1 0 UUS10UFlorida10U Cuda Systems LLC1 0 UKarl Denninger (OCSP)0"0 *H 0 X@vkY Tq/vE]5#֯MX \8LJ/V?5Da+ sJc*/r{ȼnS+ w")ąZ^DtdCOZ ~7Q '@a#ijc۴oZdB&!Ӝ-< ? HN5y 5}F|e f"V لio74zn">a1qWuɖbFeGE&3(KhixG3!#e_XƬ Ϝ/,$+;4y 'Bz<qT9_?rRUpn5 Jn&Rx/p Jyel*pN8/#9u/YP EC)TY>~/˘N[vyiDKˉ ,^" ?$T8 v& K%z8C @?K{9f`+@,| Mbia 007++0)0'+0http://cudasystems.net:88880 U 0 0 `HB0 U 0, `HB OpenSSL Generated Certificate0 U -h\Ff Y0 U #0$q}ݽʒm50 U 0karl@denninger.net0 *H Owbabɺx&Uk[ (Oj!%p MQ0I!#QH}.>~2&D}<wm_>V6 v ]f>=Nn+8;q wfΰ/RLyUG#b}n!Dր _up|_ǰc/%ۥ nN8:d;-UJd/m1~VނיnN I˾$tF1&}|?q?\đXԑ&\4V<lKۮ3%Am_(q -(cAeGX)f}-˥6cv~Kg8m~v ;|9:-iAPқ6ېn-.)<[$KJtt/L4ᖣ^Cmu4vb{+BG$M0c\[MR|0FԸP&78"4p# }D Z9;V9#>Sw"[UP710001 0 UUS10UFlorida10U Niceville10U Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H Cuda Systems LLC CA)0 `He M0 *H 1 *H 0 *H 1 151215162205Z0O *H 1B@h9hM?}]t,x ![13;مZgȎ+dCc~Dl Z > 0l *H 1_0]0 `He*0 `He0 *H 0*H 0 *H @0+0 *H (0 +71001 0 UUS10UFlorida10U Niceville10U Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H Cuda Systems LLC CA)0 *H 101 0 UUS10UFlorida10U Niceville10U Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H Cuda Systems LLC CA)0 *H F=P.~63kk 9R PMʂŭ}e,CQN,Gԏ]9Z֦U@d_zNr</|nu&~툰{ϗګWL|\5 Xᘿ+~rGI.4%WF<Q<Ba+MF~|.䔯l99Ve=f]|f!w~\Ėu]φ n~D iX3T ( oG0 Й 7N -F=zx;c SG;]#T]>1@r%Յ<#Ԓ9^=.k$mŢ*,nEyaY!q(4n]<AoJ+rwU`$ 2 [[rbr rƵs2}WWp貃d i~ (V`wE9\<ލn%{.ߥPxL|a)DX+AN'tH+Ihome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56703E2D.8050504>