Bug 215561 - ports-mgmt/poudriere-devel: -r428604: -m src= gets "sh: cc: not found"
Summary: ports-mgmt/poudriere-devel: -r428604: -m src= gets "sh: cc: not found"
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: powerpc Any
: --- Affects Only Me
Assignee: Bryan Drewery
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-12-26 00:42 UTC by Mark Millard
Modified: 2019-03-27 21:00 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback? (bdrewery)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Millard 2016-12-26 00:42:33 UTC
[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.]

Despite:

# cc --version
FreeBSD clang version 3.9.0 (tags/RELEASE_390/final 280324) (based on LLVM 3.9.0)
Target: powerpc64-unknown-freebsd12.0
Thread model: posix
InstalledDir: /usr/bin

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[2]: "/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'
+ installworld

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
build_and_install_world().]

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


Context:

# 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
Revision: 428604
Last Changed Rev: 428604


+ file=/usr/local/etc/poudriere.d/12C_powerpc64-poudriere.conf
+ [ -r /usr/local/etc/poudriere.d/12C_powerpc64-poudriere.conf ]
+ . /usr/local/etc/poudriere.d/12C_powerpc64-poudriere.conf
+ NO_ZFS=yes
+ FREEBSD_HOST=ftp://ftp.freebsd.org
+ RESOLV_CONF=/etc/resolv.conf
+ BASEFS=/usr/local/poudriere
+ USE_PORTLINT=no
+ USE_TMPFS=yes
+ DISTFILES_CACHE=/usr/ports/distfiles
+ SVN_HOST=svn.FreeBSD.org
+ CHECK_CHANGED_OPTIONS=verbose
+ CHECK_CHANGED_DEPS=yes
+ SAVE_WRKDIR=yes
+ BUILDER_HOSTNAME=FBSDG5L
+ PRESERVE_TIMESTAMP=yes
+ 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.)
Comment 1 Mark Millard 2017-03-23 01:38:34 UTC
See:

https://lists.freebsd.org/pipermail/freebsd-current/2017-March/065354.html

for a report today (2017-Mar-22) for aarch64 based on a more modern context.
Comment 2 Bryan Drewery freebsd_committer 2017-03-23 03:57:23 UTC
It's most likely the same issue as Bug 212877.  There's a patch in there if you want to try it out.
Comment 3 Walter Schwarzenfeld freebsd_triage 2019-03-27 15:15:06 UTC
Is this still relevant?
Comment 4 Mark Millard 2019-03-27 21:00:05 UTC
(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 :

/usr/local/share/poudriere/jail.sh :

       null)
               JAILFS=none
               FCT=build_native_xtools


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
original experiment.