Re: CURRENT: aarch64 /poudriere installation fails with: sh: cc: not found
On 2017-Mar-22, at 7:53 PM, Mark Millard wrote: > O. Hartmann ohartmann at walstatt.org wrote on Wed Mar 22 14:10:00 UTC 2017: > > . . . >> make[2]: "/pool/CURRENT/src/share/mk/bsd.compiler.mk" line 145: Unable >> to determine compiler type for CC=cc -target aarch64-unknown-freebsd12.0 >> --sysroot=/usr/obj/arm64.aarch64/pool/CURRENT/src/tmp >> -B/usr/local/aarch64-freebsd/bin/. Consider setting COMPILER_TYPE. >> *** Error code 1 > > . . . > > > See bugzilla 215561 for a prior report (powerpc64 context). > > > Other poudriere related notes: > > When I experimented some with poudriere I also submitted: > > 216084 > 216083 > 215561 (referenced above) > 215541 > > I've not tried much since then but will get back to it > someday. > > Comments 10 and 11 of: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216229 > > might also be relevant. In effect: avoid using CFLAGS+= > or CXXFLAGS+= in a SRCCONF/SRC_ENV_CONF file used in > poudriere. (The problem is more general than that.) > CFLAGS.clang+= and the like should work okay. Or be > sure to use a __MAKE_CONF file in poudriere for the > likes of CFLAGS+= . (But this last has issues if > system vs. port building needs different options.) > > > Other notes tied to arm64 or pine64+ 2GB specifically: > > Because you happen to be using arm64 you may want to > look at bugzilla 217239 and 217138 (which I've since > judged as likely to have the same underlying cause). > 217138's original context was tied to buildworld -j4 on > a pine64+ 2GB (but I've managed to make a small example > program or two that shows relevant behavior). > > With 2GB of RAM buildworld -j4 can force some processes > to be swapped-out at times [zero RES(ident memory)]. > There can be problems with trashed (zeroed) memory > pages when swapped back in if the memory was allocated > before the parent process forks. (That is my small > example's way of producing the issue.) The parent, child, > and more ancestor processes that swapped-out can see > zeroed memory in the same general address range(s) > as the child does. (Nasty cross-process damage.) > > There is more to it (it is complicated): See the > last half of: > > https://lists.freebsd.org/pipermail/freebsd-arm/2017-March/015934.html > > for a summary without all the code examples and the > like, including avoiding going through my learn-as-I-went > issues. (Also submitted to freebsd-hackers asking for > information.) I have occasionally types amd64 in my > various materials where it should have been arm64. > > The zeros caused my self-hosted buildworld's to stop > (sh asserting) and I had to restart them twice per > buildworld on the pine64+ 2GB (presumes certain things > were rebuilt). > > I've seen the memory trashing on an rpi3 as well, with > no device in common with the pine64+ 2GB. > > Another issue is that while I've been able to do > builds on the pine64+ 2GB I have found that running > 4 "openssl speed" commands at the same time causes > an eventual sudden/silent shutdown, probably for > insufficient thermal control. This is with 6 heat > sinks and a fan. So the pine64+ 2GB may be marginal > from that point of view. (Yep: powerd was running.) > I've not tried 2 or 3 "openssl speed"s in parallel. > Nor have a tried on a rpi3: was was targeting having > more RAM. > > > Yet other notes: > > With some local adjustments I did get as far as having > an amd64-host to-armv6/v7 cross-build environment. > But I ended up deciding that I'd need to have access to > a more substantial amd64 environment than I had used in > order to satisfy my time preferences and in order to > deal with the resource limitations of the context that > I used for the experiments --ones that I did not want > to change in that context. > > I ended up deleting the packages, jail, and all the > files involved. I'll get back to such someday. Bryan Drewery just added a Comment #19 to Bugzilla 215561: It's most likely the same issue as Bug 212877. There's a patch in there if you want to try it out. See Also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212877 === Mark Millard markmi at dsl-only.net ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT: aarch64 /poudriere installation fails with: sh: cc: not found
O. Hartmann ohartmann at walstatt.org wrote on Wed Mar 22 14:10:00 UTC 2017: . . . > make[2]: "/pool/CURRENT/src/share/mk/bsd.compiler.mk" line 145: Unable > to determine compiler type for CC=cc -target aarch64-unknown-freebsd12.0 > --sysroot=/usr/obj/arm64.aarch64/pool/CURRENT/src/tmp > -B/usr/local/aarch64-freebsd/bin/. Consider setting COMPILER_TYPE. > *** Error code 1 . . . See bugzilla 215561 for a prior report (powerpc64 context). Other poudriere related notes: When I experimented some with poudriere I also submitted: 216084 216083 215561 (referenced above) 215541 I've not tried much since then but will get back to it someday. Comments 10 and 11 of: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216229 might also be relevant. In effect: avoid using CFLAGS+= or CXXFLAGS+= in a SRCCONF/SRC_ENV_CONF file used in poudriere. (The problem is more general than that.) CFLAGS.clang+= and the like should work okay. Or be sure to use a __MAKE_CONF file in poudriere for the likes of CFLAGS+= . (But this last has issues if system vs. port building needs different options.) Other notes tied to arm64 or pine64+ 2GB specifically: Because you happen to be using arm64 you may want to look at bugzilla 217239 and 217138 (which I've since judged as likely to have the same underlying cause). 217138's original context was tied to buildworld -j4 on a pine64+ 2GB (but I've managed to make a small example program or two that shows relevant behavior). With 2GB of RAM buildworld -j4 can force some processes to be swapped-out at times [zero RES(ident memory)]. There can be problems with trashed (zeroed) memory pages when swapped back in if the memory was allocated before the parent process forks. (That is my small example's way of producing the issue.) The parent, child, and more ancestor processes that swapped-out can see zeroed memory in the same general address range(s) as the child does. (Nasty cross-process damage.) There is more to it (it is complicated): See the last half of: https://lists.freebsd.org/pipermail/freebsd-arm/2017-March/015934.html for a summary without all the code examples and the like, including avoiding going through my learn-as-I-went issues. (Also submitted to freebsd-hackers asking for information.) I have occasionally types amd64 in my various materials where it should have been arm64. The zeros caused my self-hosted buildworld's to stop (sh asserting) and I had to restart them twice per buildworld on the pine64+ 2GB (presumes certain things were rebuilt). I've seen the memory trashing on an rpi3 as well, with no device in common with the pine64+ 2GB. Another issue is that while I've been able to do builds on the pine64+ 2GB I have found that running 4 "openssl speed" commands at the same time causes an eventual sudden/silent shutdown, probably for insufficient thermal control. This is with 6 heat sinks and a fan. So the pine64+ 2GB may be marginal from that point of view. (Yep: powerd was running.) I've not tried 2 or 3 "openssl speed"s in parallel. Nor have a tried on a rpi3: was was targeting having more RAM. Yet other notes: With some local adjustments I did get as far as having an amd64-host to-armv6/v7 cross-build environment. But I ended up deciding that I'd need to have access to a more substantial amd64 environment than I had used in order to satisfy my time preferences and in order to deal with the resource limitations of the context that I used for the experiments --ones that I did not want to change in that context. I ended up deleting the packages, jail, and all the files involved. I'll get back to such someday. === Mark Millard markmi at dsl-only.net ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
CURRENT: aarch64 /poudriere installation fails with: sh: cc: not found
Hello List(s), I'm pretty new to cross compiling on FreeBSD, so to make the introduction short: amazed by the possibilities of FreeBSD on Pine64 and poudriere as the basis of our own ports repository, I try to build a repository of selected ports via poudriere for arm64.aarch64 and - fail! When installaing the jail from a prebuilt world via "-m src=...", the installation fails with: [...] make[2]: "/pool/CURRENT/src/share/mk/bsd.compiler.mk" line 145: Unable to determine compiler type for CC=cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/arm64.aarch64/pool/CURRENT/src/tmp -B/usr/local/aarch64-freebsd/bin/. Consider setting COMPILER_TYPE. *** Error code 1 Stop. make[1]: stopped in /pool/sources/CURRENT/src *** Error code 1 [...] I use the option "-m src=" with all of my jails, where for amd64 the source tree and object tree resides in /usr/src and /usr/obj respectively from a buildworld. For poudriere jails intended to be used for cross building, I checked out the whole CURRENT tree (among 11 and 10) at /pool/CURRENT/src (or /pool/11-STABLE/src or /pool/10.3-RELEASE/src) to keep the main tree clean and intact in case I have to patch too much. The hosting system is a 12-CURRENT as of recent date: 12.0-CURRENT #30 r315698: Wed Mar 22 06:09:40 CET 2017 amd64. Building a "buildworld" for the arm64.aarch64 has been performed successfully via env MAKEOBJDIRPREFIX=/pool/11-STABLE/obj SRCCONF=/dev/null \ __MAKE_CONF=/dev/null TARGET=arm64 make -j12 buildworld After a successful build, there is a object's folder structure /pool/CURRENT/obj/arm64.aarch/ containing (obviosly?) the world without a kernel. Since I use some optimisation flags and special setting in /etc/src.conf and /etc/make.conf, I needed to neutralise those settings and followed the examples and ways I've learned from using NanoBSD. Now, I try to install this world as the base of my arm64.aarch64 jail, which is supposed to build the ports tree for arm64.aarch64 platforms. As a prerequisite, I have already installed the most recent port emulators/qemu-user-static (qemu-user-static-2.8.50.g20170307) and it has been started as a service, as kldstat seems to indicate: kldstat [...] 41 0x81901000 23d0 filemon.ko 51 0x81904000 14fe imgact_binmisc.ko Well, now I try to install the jail: poudriere jail -c -j head-aarch64 -a arm64.aarch64 \ -M /pool/poudriere/jails/head-aarch64 -m src=/pool/CURRENT/src -v head and as a desperate try also with option "-x". But either way, I fail installing the jail with the error shown above. Something is missing and I think, the recommendation of setting the COMPILER_TYPE has a deeper sense here ;-) I tried to google some advices, but I stumbled only over some "simple and easy" advices which lead me to the failure seen above. Maybe nullifying the SRCCONF and __MAKE_CONF isn't a good idea at that point, but I'd like to to await the professionals advice. Thanks in advance, Oliver ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
