[I doubt that this is powerpc64 specific but that is the context I'm
working in. A devel/powerpc64-gcc based on gcc 5.3.0 built the world
and kernel that is in use, libc++ based. It is possible that I'm
mixing more than one issue together below. I extracted some material
from logged sh -x output.]
# cc --version
FreeBSD clang version 3.9.0 (tags/RELEASE_390/final 280324) (based on LLVM 3.9.0)
Thread model: posix
The following (the odd form of the command is from trying to explore
the failure of a more normal command):
# sh -x `which poudriere` -x jail -c -m src=/usr/src -J 4 -v head@309656 -j 12C_powerpc64
gets during installworld:
sh: cc: not found
make: "/usr/src/share/mk/bsd.compiler.mk" line 145: Unable to determine compiler type for CC=cc -isystem /usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/tmp/usr/include -L/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/tmp/usr/lib -B/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/tmp/usr/lib --sysroot=/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/tmp -B/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/tmp/usr/bin. Consider setting COMPILER_TYPE.
*** Error code 1
But even if COMPILER_TYPE was defined the jail is using:
+ jset 12C_powerpc64 mnt /usr/local/poudriere/jails/12C_powerpc64
which has no cc available inside it at the time. Nor would the:
+ cpdup -i0 -X /tmp/cpignore.cGd2WOOW /usr/src /usr/local/poudriere/jails/12C_powerpc64/usr/src
populate it with such. So the eventual:
+ export 'TARGET=powerpc'
+ export 'TARGET_ARCH=powerpc64'
+ export 'WITH_FAST_DEPEND=yes'
which in turn does:
+ make -C /usr/src installworld 'DESTDIR=/usr/local/poudriere/jails/12C_powerpc64' 'DB_FROM_SRC=1'
has no cc to put to use --and no prior src.conf or make.conf handling that
can contribute anything to the installworld. [src.conf is only handled in
In other words: as far as I can tell -m src= for the
ports-mgmt/poudriere-devel based jail -c when mixed with the modern system
build environment is broken: it needs but does not have cc available as
at least one blocking issue.
(I've not tried a work around to see what might be next for problems
for -m src= use.)
# uname -apKU
FreeBSD FBSDG5L 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r309656M: Tue Dec 6 21:15:55 PST 2016 markmi@FreeBSDx64:/usr/obj/powerpc64vtsc_xtoolchain_kernel/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODBG powerpc powerpc64 1200017 1200017
# svnlite info /usr/ports/ | grep "Re[plv]"
Relative URL: ^/head
Repository Root: https://svn0.us-west.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Last Changed Rev: 428604
+ [ -r /usr/local/etc/poudriere.d/12C_powerpc64-poudriere.conf ]
+ . /usr/local/etc/poudriere.d/12C_powerpc64-poudriere.conf
+ export 'MAKEOBJDIRPREFIX=/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64'
(The usage of MAKEOBJDIRPREFIX= in such a place was not clear from
the documentation but with my multiple variations for builds from the
same source I name them more explicitly.)
for a report today (2017-Mar-22) for aarch64 based on a more modern context.
It's most likely the same issue as Bug 212877. There's a patch in there if you want to try it out.
Is this still relevant?
(In reply to w.schwarzenfeld from comment #3)
I've been using things like:
jail -c -jFBSDFSSDjailCortexA53 -a arm64.aarch64 -x -m null -M /usr/obj/DESTDIRs/clang-cortexA53-installworld-poud -S /usr/src -v 13.0-CURRENT
( so -m null with -S /usr/src ). This does involve the following local change (FCT= assigning non-empty) for the -x :
It will probably be a while before I'd test using -m src=...
in a context similar to the old experiment that tried to
use it. (It was before I switched to the above way of working.)
It does appear that 212877 would have been a likely fix for the
(In reply to Walter Schwarzenfeld from comment #3)
I've tested with:
poudriere -x jail -c -m src=/usr/src -J 32 -v head@355027 -j testBugzilla215561
(with an appropriate env MAKEOBJDIRPREFIX=. . . for my
environment) and it had no cc problems. (I tested on
So I'm changing the report to status: Overcome By Events.