svn commit: r354900 - head/usr.sbin/jail

[John Baldwin]

On 11/20/19 3:04 PM, Warner Losh wrote:
> On Wed, Nov 20, 2019 at 3:09 PM John Baldwin <jhb at freebsd.org> wrote:
> 
>> On 11/20/19 10:01 AM, Warner Losh wrote:
>>> On Wed, Nov 20, 2019 at 9:54 AM Li-Wen Hsu <lwhsu at freebsd.org> wrote:
>>>
>>>> Author: lwhsu
>>>> Date: Wed Nov 20 16:54:21 2019
>>>> New Revision: 354900
>>>> URL: https://svnweb.freebsd.org/changeset/base/354900
>>>>
>>>> Log:
>>>>   Use the correct variable, also limit the scope to bfd
>>>>
>>>>   PR:           242109
>>>>   Reported by:  jhb
>>>>   Sponsored by: The FreeBSD Foundation
>>>>
>>>> Modified:
>>>>   head/usr.sbin/jail/Makefile
>>>>
>>>> Modified: head/usr.sbin/jail/Makefile
>>>>
>>>>
>> ==============================================================================
>>>> --- head/usr.sbin/jail/Makefile Wed Nov 20 16:35:58 2019
>> (r354899)
>>>> +++ head/usr.sbin/jail/Makefile Wed Nov 20 16:54:21 2019
>> (r354900)
>>>> @@ -18,7 +18,7 @@ CFLAGS+=-I. -I${.CURDIR}
>>>>  # workaround for GNU ld (GNU Binutils) 2.33.1:
>>>>  #   relocation truncated to fit: R_RISCV_GPREL_I against `.LANCHOR2'
>>>>  # https://bugs.freebsd.org/242109
>>>> -.if ${MACHINE_ARCH} == "riscv"
>>>> +.if ${LINKER_TYPE} == "bfd" && ${MACHINE} == "riscv"
>>>>
>>>
>>> MACHINE isn't the right thing to use here. It's never the proper thing in
>>> userland makefiles, unless they are interfacing with the kernel.
>>>
>>> MACHINE_CPUARCH is what you want here.
>>
>> Eh, that claim doesn't seem quite true.  src.opts.mk only uses MACHINE
>> and not
>> MACHINE_CPUARCH for example (to set _TT that is then used all over the
>> place in src.opts.mk).  My experience is that uses of *_CPUARCH are in
>> fact
>> pretty rare.
>>
> 
> However, __TT is used bogusly in many places in src.opts.mk. They are all
> relatively new related to llvm (and one for google test). MACHINE has
> always been for the kernel and MACHINE_ARCH for userland. MACHINE_CPUARCH
> was created for those architectures where we have a number of MACHINE_ARCH
> to make things easier to cope with.
> 
> I've done several sweeps of the tree over the years to keep this enforced,
> so I'm quite sure of the dichotomy...

Here are some to fix then: :)

sbin/reboot/Makefile:.if exists(${.CURDIR}/boot_${MACHINE}.8)
sbin/reboot/Makefile:MAN+=      boot_${MACHINE}.8
sbin/reboot/Makefile:MLINKS+= boot_${MACHINE}.8 boot.8
sbin/reboot/Makefile:.if ${MACHINE} == "amd64"
usr.sbin/bsdinstall/partedit/Makefile:PARTEDIT_ARCH= ${MACHINE}
usr.sbin/bsdinstall/partedit/Makefile:.if ${MACHINE} == "i386" || ${MACHINE} == "amd64"
usr.sbin/pkg/Makefile:.  if ${MACHINE} != "amd64" && ${MACHINE} != "i386"

This one also seems dubious, but in a different way:

usr.bin/Makefile:

# ARM64TODO gprof does not build
# RISCVTODO gprof does not build
.if ${MACHINE_ARCH} != "aarch64" && ${MACHINE_CPUARCH} != "riscv"
SUBDIR.${MK_TOOLCHAIN}+=        gprof
.endif

Somewhat exacerbated by the whole aarch64 vs arm64 thing and probably
confusion on when to use CPUARCH vs ARCH.

BTW, MACHINE_ARCH seems to matter just as much for the kernel.  64-bit
mips runs a "mips64" kernel, not a "mips" kernel.

With PC-98 removed, I don't think we have any cases where MACHINE !=
MACHINE_CPUARCH now?

-- 
John Baldwin