Re: CURRENT: aarch64 /poudriere installation fails with: sh: cc: not found

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:
> 
> . . .
>> 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