While this works when host supports the specified cputype however this breaks when cross compiling as for instance cortex cores aren't valid options on amd64. I guess the simple (and correct?) solution would to be to only pass cputype to target build. -------------------------------------------------------------- >>> stage 4.2: building libraries -------------------------------------------------------------- ===> lib/libcompiler_rt (obj,all,install) ===> lib/libssp_nonshared (obj,all,install) ===> lib/libgcc_eh (obj,all,install) ===> lib/libgcc_s (obj,all,install) error: unknown target CPU 'cortex-a53'
The default MAKE_CONF is '/dev/null', so I suspect something else might be going wrong here.
Sorry for the confusion, this is when you specify a file. Such as /usr/src/release/arm64/ROCKPRO64.conf ... MAKE_CONF="/etc/release-confs/make.conf" ... cat /etc/release-confs/make.conf CPUTYPE?=cortex-a53
If there's any more information needed I'll try to provide it and if testing needs to be done just ask and I'll give it a go.
I wonder if TARGET_CPUTYPE would work instead, TARGET_CPUTYPE?=cortex-a53
My files analogous to src.conf or src-env.conf for cross building (amd64->???) via system clang have lines like: XCFLAGS+= -mcpu=cortex-a72 XCXXFLAGS+= -mcpu=cortex-a72 # There is no XCPPFLAGS but XCPP gets XCFLAGS content. ACFLAGS.arm64cpuid.S+= -mcpu=cortex-a72+crypto ACFLAGS.aesv8-armx.S+= -mcpu=cortex-a72+crypto ACFLAGS.ghashv8-armx.S+= -mcpu=cortex-a72+crypto I've only experimented with such specific control for cortex-a7, cortex-a53, cortex-a57, and cortex-a72, i.e., the armv7 and aarch64 systems that I've had access to, not targetting powerpc64, powerpc, or amd64. -mcpu= implicitly picks the matching -march= value and also sets the -mtune= value. The A53, A57, and A72 share the same -march= (armv8-a if I remember the command line notation correctly) but can have very different tuning. (In part this is because the A53 does not do many things that the architecture allows, such as: it only executes in order.) I've not dealt with using the release script in years, so I make no specific claims for that context. And even for just use with make, the above probably steps into "you are on your own" space. But at the time I adopted the technique, I did not find any way to avoid that status while doing the targeting via the style of build. I've not had any troubles attributed to the above.
(In reply to Mark Millard from comment #5) By the way, for self hosted (not cross builds) I use the likes of: # Use of the .clang 's here avoids # interfering with other C<?>FLAGS # usage, such as ?= usage. CFLAGS.clang+= -mcpu=cortex-a72 CXXFLAGS.clang+= -mcpu=cortex-a72 CPPFLAGS.clang+= -mcpu=cortex-a72 ACFLAGS.arm64cpuid.S+= -mcpu=cortex-a72+crypto ACFLAGS.aesv8-armx.S+= -mcpu=cortex-a72+crypto ACFLAGS.ghashv8-armx.S+= -mcpu=cortex-a72+crypto This requires that the the implicit -march= value to be compatible with the host. (I've never faced a context with strongly related -march values, such as a -march=armv8-a host trying to compile to target -march=armv8.2-a instruction set extensions that an armv8-a would reject. TARGET and TARGET_ARCH are not that detailed but determine what is considered a cross-build in the build system.)
Unfortunately it didn't seem to fix the issue -------------------------------------------------------------- >>> stage 4.2: building libraries -------------------------------------------------------------- ===> lib/libcompiler_rt (obj,all,install) ===> lib/libssp_nonshared (obj,all,install) ===> lib/libgcc_eh (obj,all,install) ===> lib/libgcc_s (obj,all,install) error: unknown target CPU 'cortex-a53' note: valid target CPU values are: nocona, core2, penryn, bonnell, atom, silvermont, slm, goldmont, goldmont-plus, tremont, nehalem, corei7, westmere, sandybridge, corei7-avx, ivybridge, core-avx-i, haswell, core-avx2, broadwell, skylake, skylake-avx512, skx, cascadelake, cooperlake, cannonlake, icelake-client, icelake-server, tigerlake, knl, knm, k8, athlon64, athlon-fx, opteron, k8-sse3, athlon64-sse3, opteron-sse3, amdfam10, barcelona, btver1, btver2, bdver1, bdver2, bdver3, bdver4, znver1, znver2, x86-64 --- int_util.o --- *** [int_util.o] Error code 1 make[4]: stopped in /scratch/usr/src/lib/libgcc_eh --- lib/libgcc_s__PL --- make[3]: stopped in /scratch/usr/src --- lib/libcompiler_rt__PL --- make[3]: stopped in /scratch/usr/src error: unknown target CPU 'cortex-a53' note: valid target CPU values are: nocona, core2, penryn, bonnell, atom, silvermont, slm, goldmont, goldmont-plus, tremont, nehalem, corei7, westmere, sandybridge, corei7-avx, ivybridge, core-avx-i, haswell, core-avx2, broadwell, skylake, skylake-avx512, skx, cascadelake, cooperlake, cannonlake, icelake-client, icelake-server, tigerlake, knl, knm, k8, athlon64, athlon-fx, opteron, k8-sse3, athlon64-sse3, opteron-sse3, amdfam10, barcelona, btver1, btver2, bdver1, bdver2, bdver3, bdver4, znver1, znver2, x86-64 error: unknown target CPU 'cortex-a53' note: valid target CPU values are: nocona, core2, penryn, bonnell, atom, silvermont, slm, goldmont, goldmont-plus, tremont, nehalem, corei7, westmere, sandybridge, corei7-avx, ivybridge, core-avx-i, haswell, core-avx2, broadwell, skylake, skylake-avx512, skx, cascadelake, cooperlake, cannonlake, icelake-client, icelake-server, tigerlake, knl, knm, k8, athlon64, athlon-fx, opteron, k8-sse3, athlon64-sse3, opteron-sse3, amdfam10, barcelona, btver1, btver2, bdver1, bdver2, bdver3, bdver4, znver1, znver2, x86-64
(In reply to daniel.engberg.lists from comment #7) Hard to tell if you did what Ed listed (#4) vs. what I listed (#5/#6) or both (at different times). Does your MAKE_CONF or SRC_CONF file specify: TARGET=arm64 TARGET_ARCH=aarch64 so that the likes of -target x86_64-unknown-freebsd14.0 will not be used but the likes of -target aarch64-unknown-freebsd14.0 will be used? The "valid target CPU values" listed are all x86-64/amd64 variations. Is it system clang/clang++ that is in use? If it is, is there any WITHOUT_LLVM_TARGET_??? use? Does the compile-command-line also specify -target x86_64-unknown-freebsd14.0 (or 13.0) or some such that would restrict the possibilities? Is the context gcc/g++ based instead? Is the build reporting things like: --- buildworld --- make[1]: "/usr/src/Makefile.inc1" line 320: SYSTEM_COMPILER: Determined that CC=cc matches the source tree. Not bootstrapping a cross-compiler. make[1]: "/usr/src/Makefile.inc1" line 325: SYSTEM_LINKER: Determined that LD=ld matches the source tree. Not bootstrapping a cross-linker. You might want to provide more of the content from input files used with MAKE_CONF and SRC_CONF and such and output material from the build showing the command lines being used to do the compiles.
I apologize, I did try what Ed suggested
Hmm.... Looking at the script I think the easiest(?) solution would be introducing CPUTYPE here https://cgit.freebsd.org/src/tree/release/release.sh#n372 as a separate variable but I'm not sure if that's the correct way to go about it.
Closing this as it needs more work for an acceptable implementation
See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254319 for a change that was made to allow distinctions between the CHROOT_* and RELEASE_* related build activities. The comments cover some about being selective with the target cpu type selection and other background related to the change. The commit is shown in: https://lists.freebsd.org/pipermail/dev-commits-src-main/2021-March/002867.html