Date: Wed, 22 Mar 2017 21:35:49 -0700 From: Mark Millard <markmi@dsl-only.net> To: ohartmann@walstatt.org Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: CURRENT: aarch64 /poudriere installation fails with: sh: cc: not found Message-ID: <77B361DA-27CA-4F95-B0B1-069993DFD6EB@dsl-only.net> In-Reply-To: <185E974A-A52A-4A2D-A5E2-B9EA06A9FB56@dsl-only.net> References: <185E974A-A52A-4A2D-A5E2-B9EA06A9FB56@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2017-Mar-22, at 7:53 PM, Mark Millard <markmi at dsl-only.net> wrote: > O. Hartmann ohartmann at walstatt.org wrote on Wed Mar 22 14:10:00 UTC = 2017: >=20 > . . . >> make[2]: "/pool/CURRENT/src/share/mk/bsd.compiler.mk" line 145: = Unable >> to determine compiler type for CC=3Dcc -target = aarch64-unknown-freebsd12.0 >> --sysroot=3D/usr/obj/arm64.aarch64/pool/CURRENT/src/tmp >> -B/usr/local/aarch64-freebsd/bin/. Consider setting COMPILER_TYPE. >> *** Error code 1 >=20 > . . . >=20 >=20 > See bugzilla 215561 for a prior report (powerpc64 context). >=20 >=20 > Other poudriere related notes: >=20 > When I experimented some with poudriere I also submitted: >=20 > 216084 > 216083 > 215561 (referenced above) > 215541 >=20 > I've not tried much since then but will get back to it > someday. >=20 > Comments 10 and 11 of: >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216229 >=20 > might also be relevant. In effect: avoid using CFLAGS+=3D > or CXXFLAGS+=3D in a SRCCONF/SRC_ENV_CONF file used in > poudriere. (The problem is more general than that.) > CFLAGS.clang+=3D and the like should work okay. Or be > sure to use a __MAKE_CONF file in poudriere for the > likes of CFLAGS+=3D . (But this last has issues if > system vs. port building needs different options.) >=20 >=20 > Other notes tied to arm64 or pine64+ 2GB specifically: >=20 > 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). >=20 > 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.) >=20 > There is more to it (it is complicated): See the > last half of: >=20 > https://lists.freebsd.org/pipermail/freebsd-arm/2017-March/015934.html >=20 > 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. >=20 > 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). >=20 > I've seen the memory trashing on an rpi3 as well, with > no device in common with the pine64+ 2GB. >=20 > 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. >=20 >=20 > Yet other notes: >=20 > 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. >=20 > 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=3D212877 =3D=3D=3D Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?77B361DA-27CA-4F95-B0B1-069993DFD6EB>