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