Re: svn commit: r354900 - head/usr.sbin/jail
Thanks for the fixes and sorry for the breakage.
While others might work on more proper fixes. Does it make sense to
have the attached patch to fix riscv* build?
BTW, ${LINKER_TYPE} == "bfd" seems causing failure in the clean stage,
that's why it didn't be caught in my test and CI, they have
"-DNO_CLEAN"
Li-Wen
Index: usr.sbin/jail/Makefile
===
--- usr.sbin/jail/Makefile (revision 354935)
+++ usr.sbin/jail/Makefile (working copy)
@@ -15,6 +15,13 @@
YFLAGS+=-v
CFLAGS+=-I. -I${.CURDIR}
+# workaround for riscv* with GNU ld (GNU Binutils) 2.33.1:
+# relocation truncated to fit: R_RISCV_GPREL_I against `.LANCHOR2'
+# https://bugs.freebsd.org/242109
+.if ${MACHINE_CPUARCH:Mriscv*}
+CFLAGS+=-Wl,--no-relax
+.endif
+
.if ${MK_INET6_SUPPORT} != "no"
CFLAGS+= -DINET6
.endif
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r354900 - head/usr.sbin/jail
On Wed, Nov 20, 2019 at 11:19 PM Dimitry Andric wrote: > Yes, such a table would be extremely helpful. :) > Yes. Committed. Great idea. Committed with some verbage about which one to use to. Warner ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r354900 - head/usr.sbin/jail
I write: > jhb writes: > >> With PC-98 removed, I don't think we have any cases where MACHINE != >> MACHINE_CPUARCH now? >> > > Well, there's arm64 / aarch64. > And riscv / riscv64. Warner ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r354900 - head/usr.sbin/jail
On Wed, Nov 20, 2019 at 11:19 PM Dimitry Andric wrote:
> On 21 Nov 2019, at 01:44, John Baldwin wrote:
> >
> > On 11/20/19 3:42 PM, Bjoern A. Zeeb wrote:
> >> On 20 Nov 2019, at 23:32, John Baldwin wrote:
> ...
> >> You can however find more of these elsewhere:
> >>
> >> ../lib/libc/tests/sys/Makefile:.if ${MACHINE_CPUARCH} != "aarch64" &&
> >> ${MACHINE_CPUARCH} != "riscv"
> >> ../lib/libcompiler_rt/Makefile.inc:.if ${MACHINE_CPUARCH} == "aarch64"
> >> || ${MACHINE_CPUARCH} == "riscv"
> >> ../stand/libsa/Makefile:.if ${MACHINE_CPUARCH} == "aarch64" ||
> >> ${MACHINE_CPUARCH} == "riscv"
> >> ../usr.bin/Makefile:.if ${MACHINE_ARCH} != "aarch64" &&
> >> ${MACHINE_CPUARCH} != "riscv"
> >> ../usr.bin/gprof/Makefile:.if ${MACHINE_ARCH} != "aarch64" &&
> >> ${MACHINE_ARCH} != "riscv" && \
> >
> > The tests comparing MACHINE_CPUARCH against aarch64 are confusing indeed.
> > My understanding is that MACHINE_CPUARCH is arm64 for aarch64? It's kind
> > of hard to guess since arch(7) goes to great length to try to describe
> > these variables but doesn't give a handy table of what they actually are
> > for the various architectures.
>
> Yes, such a table would be extremely helpful. :)
>
Fair point. It does go on at length for all the MACHINE_ARCH types, but
doesn't list the plain MACHINE_CPUARCH. In all cases, it is either the one
MACHINE_ARCH supported, or the common prefix of all the MACHINE_ARCH
supported (though when we delete armv5, that will become slightly
inaccurate, so a table is likely good).
Warner
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r354900 - head/usr.sbin/jail
On Wed, Nov 20, 2019 at 4:32 PM John Baldwin wrote:
> On 11/20/19 3:04 PM, Warner Losh wrote:
> > On Wed, Nov 20, 2019 at 3:09 PM John Baldwin wrote:
> >
> >> On 11/20/19 10:01 AM, Warner Losh wrote:
> >>> On Wed, Nov 20, 2019 at 9:54 AM Li-Wen Hsu 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"
>
I'm not sure these are wrong... reboot is based on the kernel we're
running, though. partedit is based on what kind of partition scheme the
kernel wants. pkg is just wrong, though. Traditionally in BSD, different
ways of booting usually went hand and hand with needing different kernels.
Though after BSD passed from mini/micro computers where this was true into
embedded things got blurrier. Likewise with the partitioning schemes: those
used to be different for every type of computer, but now have standardized
around GPT with a few legacy systems like MBR and APM lingering on. BSD
labels were originally invented to have a standard way to label a disk, but
even that grew a lot of variations.
> 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
>
Yes. That's likely incorrect.
> Somewhat exacerbated by the whole aarch64 vs arm64 thing and probably
confusion on when to use CPUARCH vs ARCH.
When I invented CPUARCH, I didn't make it as clean as I'd like. It's always
for 'what directory do we use in the tree' and is also convenient for other
things. It was thought you'd use CPUARCH when you are testing generically
for an arch. You'd use MACHINE_ARCH when you needed a specific one (so both
of these should be MACHINE_CPUARCH). The notion was you'd only need to use
MACHINE_ARCH rarely in ifdefs and usually only inside of system-wide .mk
files.
> BTW, MACHINE_ARCH seems to matter just as much for the kernel. 64-bit
> mips runs a "mips64" kernel, not a "mips" kernel.
>
It does.
With PC-98 removed, I don't think we have any cases where MACHINE !=
> MACHINE_CPUARCH now?
>
Well, there's arm64 / aarch64.
I'm not at all opposed to changing the definitions, but they are what I've
been saying. I've done a lot of cleanup of mis-uses over the last 10 or 15
years, so these characterizations are correct. I'll admit I've done not the
best job at documenting it, though. Coming up with new definitions is
fraught, I'd think, since it's easy to have a notion of what the right
thing is, but
Re: svn commit: r354900 - head/usr.sbin/jail
On 21 Nov 2019, at 01:44, John Baldwin wrote:
>
> On 11/20/19 3:42 PM, Bjoern A. Zeeb wrote:
>> On 20 Nov 2019, at 23:32, John Baldwin wrote:
...
>> You can however find more of these elsewhere:
>>
>> ../lib/libc/tests/sys/Makefile:.if ${MACHINE_CPUARCH} != "aarch64" &&
>> ${MACHINE_CPUARCH} != "riscv"
>> ../lib/libcompiler_rt/Makefile.inc:.if ${MACHINE_CPUARCH} == "aarch64"
>> || ${MACHINE_CPUARCH} == "riscv"
>> ../stand/libsa/Makefile:.if ${MACHINE_CPUARCH} == "aarch64" ||
>> ${MACHINE_CPUARCH} == "riscv"
>> ../usr.bin/Makefile:.if ${MACHINE_ARCH} != "aarch64" &&
>> ${MACHINE_CPUARCH} != "riscv"
>> ../usr.bin/gprof/Makefile:.if ${MACHINE_ARCH} != "aarch64" &&
>> ${MACHINE_ARCH} != "riscv" && \
>
> The tests comparing MACHINE_CPUARCH against aarch64 are confusing indeed.
> My understanding is that MACHINE_CPUARCH is arm64 for aarch64? It's kind
> of hard to guess since arch(7) goes to great length to try to describe
> these variables but doesn't give a handy table of what they actually are
> for the various architectures.
Yes, such a table would be extremely helpful. :)
-Dimitry
signature.asc
Description: Message signed with OpenPGP
Re: svn commit: r354900 - head/usr.sbin/jail
On Wed, Nov 20, 2019 at 04:44:58PM -0800, John Baldwin wrote:
> On 11/20/19 3:42 PM, Bjoern A. Zeeb wrote:
> > On 20 Nov 2019, at 23:32, John Baldwin wrote:
> >
> > Hijacking a side-thread:
> >
> > PreS: I think we have way too many of these options and should just
> > remove 3/4 of them again or someone build a proper matrix documenting
> > them all and in which case to use in the developers handbook ;-)
> >
> >> 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.
> >
> > This particular case could actually be removed as I thought I made that
> > at least compile when I was working on s390x:
> > https://svnweb.freebsd.org/base?view=revision=351329
> >
> >
> > You can however find more of these elsewhere:
> >
> > ../lib/libc/tests/sys/Makefile:.if ${MACHINE_CPUARCH} != "aarch64" &&
> > ${MACHINE_CPUARCH} != "riscv"
> > ../lib/libcompiler_rt/Makefile.inc:.if ${MACHINE_CPUARCH} == "aarch64"
> > || ${MACHINE_CPUARCH} == "riscv"
> > ../stand/libsa/Makefile:.if ${MACHINE_CPUARCH} == "aarch64" ||
> > ${MACHINE_CPUARCH} == "riscv"
> > ../usr.bin/Makefile:.if ${MACHINE_ARCH} != "aarch64" &&
> > ${MACHINE_CPUARCH} != "riscv"
> > ../usr.bin/gprof/Makefile:.if ${MACHINE_ARCH} != "aarch64" &&
> > ${MACHINE_ARCH} != "riscv" && \
>
> The tests comparing MACHINE_CPUARCH against aarch64 are confusing indeed.
> My understanding is that MACHINE_CPUARCH is arm64 for aarch64? It's kind
> of hard to guess since arch(7) goes to great length to try to describe
> these variables but doesn't give a handy table of what they actually are
> for the various architectures.
>
This breaks the build, regardless.
===> usr.sbin/jail (cleandir)
===> usr.bin/procstat/tests (cleandir)
make[4]: "/releng/13-amd64-GENERIC-snap/usr/src/usr.sbin/jail/Makefile" line
21: Malformed conditional (${LINKER_TYPE} == "bfd" && ${MACHINE} == "riscv")
===> usr.bin/rctl (cleandir)
make[4]: Fatal errors encountered -- cannot continue
make[4]: stopped in /releng/13-amd64-GENERIC-snap/usr/src/usr.sbin/jail
--- cleandir_subdir_usr.sbin/jail ---
*** [cleandir_subdir_usr.sbin/jail] Error code 1
Glen
signature.asc
Description: PGP signature
Re: svn commit: r354900 - head/usr.sbin/jail
On 11/20/19 3:42 PM, Bjoern A. Zeeb wrote:
> On 20 Nov 2019, at 23:32, John Baldwin wrote:
>
> Hijacking a side-thread:
>
> PreS: I think we have way too many of these options and should just
> remove 3/4 of them again or someone build a proper matrix documenting
> them all and in which case to use in the developers handbook ;-)
>
>> 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.
>
> This particular case could actually be removed as I thought I made that
> at least compile when I was working on s390x:
> https://svnweb.freebsd.org/base?view=revision=351329
>
>
> You can however find more of these elsewhere:
>
> ../lib/libc/tests/sys/Makefile:.if ${MACHINE_CPUARCH} != "aarch64" &&
> ${MACHINE_CPUARCH} != "riscv"
> ../lib/libcompiler_rt/Makefile.inc:.if ${MACHINE_CPUARCH} == "aarch64"
> || ${MACHINE_CPUARCH} == "riscv"
> ../stand/libsa/Makefile:.if ${MACHINE_CPUARCH} == "aarch64" ||
> ${MACHINE_CPUARCH} == "riscv"
> ../usr.bin/Makefile:.if ${MACHINE_ARCH} != "aarch64" &&
> ${MACHINE_CPUARCH} != "riscv"
> ../usr.bin/gprof/Makefile:.if ${MACHINE_ARCH} != "aarch64" &&
> ${MACHINE_ARCH} != "riscv" && \
The tests comparing MACHINE_CPUARCH against aarch64 are confusing indeed.
My understanding is that MACHINE_CPUARCH is arm64 for aarch64? It's kind
of hard to guess since arch(7) goes to great length to try to describe
these variables but doesn't give a handy table of what they actually are
for the various architectures.
--
John Baldwin
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r354900 - head/usr.sbin/jail
On 20 Nov 2019, at 23:32, John Baldwin wrote:
Hijacking a side-thread:
PreS: I think we have way too many of these options and should just
remove 3/4 of them again or someone build a proper matrix documenting
them all and in which case to use in the developers handbook ;-)
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.
This particular case could actually be removed as I thought I made that
at least compile when I was working on s390x:
https://svnweb.freebsd.org/base?view=revision=351329
You can however find more of these elsewhere:
../lib/libc/tests/sys/Makefile:.if ${MACHINE_CPUARCH} != "aarch64" &&
${MACHINE_CPUARCH} != "riscv"
../lib/libcompiler_rt/Makefile.inc:.if ${MACHINE_CPUARCH} == "aarch64"
|| ${MACHINE_CPUARCH} == "riscv"
../stand/libsa/Makefile:.if ${MACHINE_CPUARCH} == "aarch64" ||
${MACHINE_CPUARCH} == "riscv"
../usr.bin/Makefile:.if ${MACHINE_ARCH} != "aarch64" &&
${MACHINE_CPUARCH} != "riscv"
../usr.bin/gprof/Makefile:.if ${MACHINE_ARCH} != "aarch64" &&
${MACHINE_ARCH} != "riscv" && \
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r354900 - head/usr.sbin/jail
On 11/20/19 3:04 PM, Warner Losh wrote:
> On Wed, Nov 20, 2019 at 3:09 PM John Baldwin wrote:
>
>> On 11/20/19 10:01 AM, Warner Losh wrote:
>>> On Wed, Nov 20, 2019 at 9:54 AM Li-Wen Hsu 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
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r354900 - head/usr.sbin/jail
On Wed, Nov 20, 2019 at 3:09 PM John Baldwin wrote:
> On 11/20/19 10:01 AM, Warner Losh wrote:
> > On Wed, Nov 20, 2019 at 9:54 AM Li-Wen Hsu 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...
Warner
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r354900 - head/usr.sbin/jail
On 11/20/19 10:01 AM, Warner Losh wrote:
> On Wed, Nov 20, 2019 at 9:54 AM Li-Wen Hsu 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.
--
John Baldwin
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r354900 - head/usr.sbin/jail
On Wed, Nov 20, 2019 at 9:54 AM Li-Wen Hsu 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.
Warner
> CFLAGS+=-Wl,--no-relax
> .endif
>
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r354900 - head/usr.sbin/jail
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"
CFLAGS+=-Wl,--no-relax
.endif
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
