Re: aarch64-arm64 fails to build kernel 12-current raspberry pi 3
On 14/07/2018 11:15, Ronald Klop wrote: What is RPI3? Mine runs GENERIC and there is no RPI3 config in /usr/src/sys/arm64/conf. I can find RPI2 in sys/arm/conf. RPI3 is the same as GENERIC-NODEBUG, apart from the ident string which is also RPI3. (was mentioned at the start of the thread which branched off) -- J. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: aarch64-arm64 fails to build kernel 12-current raspberry pi 3
On Fri, 13 Jul 2018 12:15:22 +0200, tech-lists wrote: On 12/07/2018 19:32, Dimitry Andric wrote: No, it's because sys/crypto/armv8/armv8_crypto_wrap.c includes , an intrinsics header, which in turn requires . This was introduced inhttps://svnweb.freebsd.org/changeset/base/308921, and at the time resulted in similar build failures, specifically when one attempted to build a new kernel, without building world or a new toolchain first. Hi, Ok, it's finished building and installing. The command I used was this: # make -j10 buildworld && make -j10 buildkernel KERNCONF=RPI3 What is RPI3? Mine runs GENERIC and there is no RPI3 config in /usr/src/sys/arm64/conf. I can find RPI2 in sys/arm/conf. Regards, Ronald. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: aarch64-arm64 fails to build kernel 12-current raspberry pi 3
On 2018-Jul-13, at 3:15 AM, tech-lists wrote: > On 12/07/2018 19:32, Dimitry Andric wrote: >> No, it's because sys/crypto/armv8/armv8_crypto_wrap.c includes >> , an intrinsics header, which in turn requires . >> This was introduced inhttps://svnweb.freebsd.org/changeset/base/308921, >> and at the time resulted in similar build failures, specifically when >> one attempted to build a new kernel, without building world or a new >> toolchain first. > > Hi, > > Ok, it's finished building and installing. The command I used was this: > > # make -j10 buildworld && make -j10 buildkernel KERNCONF=RPI3 make -j10 buildworld buildkernel KERNCONF=RPI3 would have worked. > and it all built, (so I'll close the PR I opened). Then I did make > installkernel KERNCONF=RPI3 and because I thought might as well install > everything now it's built, mergemaster -p and make installworld && > mergemaster -Ui. > > So I take it then, that every time I want to build a kernel, I either have to > do the above or use make kernel-toolchain. Is this correct? If you first clear out the old build, then such would be true. (Where, for targeting aarch64, kernel-toolchain needs to be avoided.) But you can buildkernel using the results of the existing buildworld (or kernel-toolchain if it applies) when it is okay to not clear out the old build first. (kernel developers doing kernel development likely do this a lot.) Another way to make tradeoffs is to use META_MODE so that partial rebuilds are done, avoiding some of the strictly unnecessary rebuild activity. This would involve buildworld or kernel-toolchain (as appropriate for the target architecture). === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: aarch64-arm64 fails to build kernel 12-current raspberry pi 3
On 12/07/2018 19:32, Dimitry Andric wrote: No, it's because sys/crypto/armv8/armv8_crypto_wrap.c includes , an intrinsics header, which in turn requires . This was introduced inhttps://svnweb.freebsd.org/changeset/base/308921, and at the time resulted in similar build failures, specifically when one attempted to build a new kernel, without building world or a new toolchain first. Hi, Ok, it's finished building and installing. The command I used was this: # make -j10 buildworld && make -j10 buildkernel KERNCONF=RPI3 and it all built, (so I'll close the PR I opened). Then I did make installkernel KERNCONF=RPI3 and because I thought might as well install everything now it's built, mergemaster -p and make installworld && mergemaster -Ui. So I take it then, that every time I want to build a kernel, I either have to do the above or use make kernel-toolchain. Is this correct? thanks, -- J. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: aarch64-arm64 fails to build kernel 12-current raspberry pi 3
On 2018-Jul-12, at 11:32 AM, Dimitry Andric wrote:
> On 12 Jul 2018, at 15:23, Mark Millard via freebsd-toolchain
> wrote:
>>
>> On 2018-Jul-12, at 2:44 AM, tech-lists wrote:
>>
>>> On 11/07/2018 17:21, Mark Millard wrote:
It seems from the quoted material that neither kernel-toolchain nor
build world was done before buildkernel . My understanding is that
the intent is that one or the other be done first. (But for aarch64
currently only buildworld works.)
>>>
>>> Thanks for this. I'm running a buildworld now.
>>>
>>> For how long has it been the case that buildworld is needed for
>>> buildkernel? Coming from amd64 and before that, i386, in situations where
>>> I've only wanted to install a custom kernel, I was firstly used to making
>>> and installing it from /sys/{i386,amd64}/conf. Then that broke a number of
>>> years ago. Then got used to making kernel in /usr/src with make buildkernel
>>> && make installkernel. And now this is broken, on aarch64-arm64. Nobody
>>> knows if it's accidental or policy.
>>
>> It has been true since clang added use of stdint.h to the kernel build.
>> Prior to this stdint.h was not needed to build the kernel for any
>> architecture (as far as I know).
>
> No, it's because sys/crypto/armv8/armv8_crypto_wrap.c includes
> , an intrinsics header, which in turn requires .
>
> This was introduced in https://svnweb.freebsd.org/changeset/base/308921,
> and at the time resulted in similar build failures, specifically when
> one attempted to build a new kernel, without building world or a new
> toolchain first.
Sorry. I was distracted this morning and should have cross checked
my claims instead of quickly babbling off the top of my head.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: aarch64-arm64 fails to build kernel 12-current raspberry pi 3
On 12 Jul 2018, at 15:23, Mark Millard via freebsd-toolchain
wrote:
>
> On 2018-Jul-12, at 2:44 AM, tech-lists wrote:
>
>> On 11/07/2018 17:21, Mark Millard wrote:
>>> It seems from the quoted material that neither kernel-toolchain nor
>>> build world was done before buildkernel . My understanding is that
>>> the intent is that one or the other be done first. (But for aarch64
>>> currently only buildworld works.)
>>
>> Thanks for this. I'm running a buildworld now.
>>
>> For how long has it been the case that buildworld is needed for buildkernel?
>> Coming from amd64 and before that, i386, in situations where I've only
>> wanted to install a custom kernel, I was firstly used to making and
>> installing it from /sys/{i386,amd64}/conf. Then that broke a number of years
>> ago. Then got used to making kernel in /usr/src with make buildkernel &&
>> make installkernel. And now this is broken, on aarch64-arm64. Nobody knows
>> if it's accidental or policy.
>
> It has been true since clang added use of stdint.h to the kernel build.
> Prior to this stdint.h was not needed to build the kernel for any
> architecture (as far as I know).
No, it's because sys/crypto/armv8/armv8_crypto_wrap.c includes
, an intrinsics header, which in turn requires .
This was introduced in https://svnweb.freebsd.org/changeset/base/308921,
and at the time resulted in similar build failures, specifically when
one attempted to build a new kernel, without building world or a new
toolchain first.
-Dimitry
signature.asc
Description: Message signed with OpenPGP
Re: aarch64-arm64 fails to build kernel 12-current raspberry pi 3
On 2018-Jul-12, at 2:44 AM, tech-lists wrote:
> On 11/07/2018 17:21, Mark Millard wrote:
>> It seems from the quoted material that neither kernel-toolchain nor
>> build world was done before buildkernel . My understanding is that
>> the intent is that one or the other be done first. (But for aarch64
>> currently only buildworld works.)
>
> Thanks for this. I'm running a buildworld now.
>
> For how long has it been the case that buildworld is needed for buildkernel?
> Coming from amd64 and before that, i386, in situations where I've only wanted
> to install a custom kernel, I was firstly used to making and installing it
> from /sys/{i386,amd64}/conf. Then that broke a number of years ago. Then got
> used to making kernel in /usr/src with make buildkernel && make
> installkernel. And now this is broken, on aarch64-arm64. Nobody knows if it's
> accidental or policy.
It has been true since clang added use of stdint.h to the kernel build.
Prior to this stdint.h was not needed to build the kernel for any
architecture (as far as I know).
As I remember, in C99 or later stdint.h is one of the headers
required for a conforming freestanding implementation of C99+.
stdint.h was added to C in C99. It was intended to be the subset
of the older inttypes.h that was suitable for freestanding
environments. inttypes.h is defined to include stdint.h for
C99 and later as I remember (or to behave as-if it had?).
https://www.freebsd.org/cgi/man.cgi?build(7) is very explicit about what
is supposed to be the case relative to kernel-toolchain use:
kernel-toolchain Rebuild the tools needed for kernel compilation. Use
this if you did not do a buildworld first.
In other words: buildkernel is not intended to be self-contained/sufficient
according to the build documentation but buildworld should not be required.
Note the difference in the buildkernel and buildworld descriptions, given
the above:
buildkernel Rebuild the kernel and the kernel modules. The object
directory can be changed from the default /usr/obj by
setting the MAKEOBJDIRPREFIX make(1) variable.
vs.
buildworld Build everything but the kernel, configure files in etc,
and release. The object directory can be changed from
the default /usr/obj by setting the MAKEOBJDIRPREFIX
make(1) variable. The actual build location prefix used
is ${MAKEOBJDIRPREFIX}${.CURDIR} for native builds, and
${MAKEOBJDIRPREFIX}/${TARGET}${.CURDIR} for cross builds
and native builds with variable CROSS_BUILD_TESTING set.
Currently, overall, FreeBSD does not meet its own criteria for aarch64 relative
to kernel-toolchain .
As far as I can tell the issue can be summarized relative to kernel-toolchain
by saying that kernel-toolchain does not currently establish a (full)
freestanding C99 environment relative to the headers but clang requires
(at least) one of the missing items ( stdint.h ) for aarch64.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: aarch64-arm64 fails to build kernel 12-current raspberry pi 3
On 11/07/2018 17:21, Mark Millard wrote:
It seems from the quoted material that neither kernel-toolchain nor
build world was done before buildkernel . My understanding is that
the intent is that one or the other be done first. (But for aarch64
currently only buildworld works.)
Thanks for this. I'm running a buildworld now.
For how long has it been the case that buildworld is needed for
buildkernel? Coming from amd64 and before that, i386, in situations
where I've only wanted to install a custom kernel, I was firstly used to
making and installing it from /sys/{i386,amd64}/conf. Then that broke a
number of years ago. Then got used to making kernel in /usr/src with
make buildkernel && make installkernel. And now this is broken, on
aarch64-arm64. Nobody knows if it's accidental or policy.
--
J.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: aarch64-arm64 fails to build kernel 12-current raspberry pi 3
tech-lists tech-lists at zyxst.net wrote on Wed Jul 11 11:42:58 UTC 2018 : > Hello lists [x-posted to -current where it's also relevant] > > 12-current-arm64 fails to build generic-nodebug kernel > > context: > 12.0-CURRENT #0 r336134: Mon Jul 9 GENERIC arm64 (this is the older rpi3B+) > > > root at rpi3 > :/usr/src# svnlite info > Path: . > Working Copy Root Path: /ext/src > URL: > https://svn.freebsd.org/base/head > > Relative URL: ^/head > Repository Root: > https://svn.freebsd.org/base > > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 336195 > Node Kind: directory > Schedule: normal > Last Changed Author: eugen > Last Changed Rev: 336195 > Last Changed Date: 2018-07-11 10:41:50 +0100 (Wed, 11 Jul 2018) > > Some dirs on /usr are symlinked to a 1TB external disk. Swap is on the > external disk. Made sure there was no src.conf or make.conf present: > > > root at rpi3 > :/root# cd /etc > > root at rpi3 > :/etc# mv src.conf old.src.conf > > root at rpi3 > :/etc# mv make.conf old.make.conf > > root at rpi3 > :/etc# cd /usr/src > > > root at rpi3 > :/usr/src# rm -rf /ext/obj > > root at rpi3 > :/usr/src# mkdir /ext/obj > > root at rpi3 > :/usr/src# ls -lah /usr > total 72 > drwxr-xr-x 12 root wheel 512B Jul 10 11:15 . > drwxr-xr-x 20 root wheel 512B Jul 10 18:45 .. > drwxr-xr-x 2 root wheel 7.5K Jul 9 20:45 bin > drwxr-xr-x 2 root wheel 512B Jul 10 11:15 home > drwxr-xr-x 56 root wheel 6.5K Jul 9 20:44 include > drwxr-xr-x 10 root wheel16K Jul 9 20:45 lib > drwxr-xr-x 5 root wheel 512B Jul 9 20:28 lib32 > drwxr-xr-x 5 root wheel 512B Jul 9 20:28 libdata > drwxr-xr-x 9 root wheel 1.5K Jul 9 20:45 libexec > lrwxr-xr-x 1 root wheel10B Jul 10 11:43 local -> /ext/local > lrwxr-xr-x 1 root wheel 8B Jul 10 11:41 obj -> /ext/obj > lrwxr-xr-x 1 root wheel10B Jul 10 11:41 ports -> /ext/ports > drwxr-xr-x 2 root wheel 5.0K Jul 9 20:45 sbin > drwxr-xr-x 29 root wheel 512B Jul 9 20:28 share > lrwxr-xr-x 1 root wheel 8B Jul 10 11:41 src -> /ext/src > drwxr-xr-x 15 root wheel 512B Jul 9 20:46 tests > > > root at rpi3 > :/usr/src# make -j10 cleanworld && make -j10 cleandir && make > -j10 clean <--- just to make absolutely sure > > [...] > > RPI3 is just a copy of GENERIC-NODEBUG. it looks like this: > > include GENERIC > > ident RPI3 > > nooptions INVARIANTS > nooptions INVARIANT_SUPPORT > nooptions WITNESS > nooptions WITNESS_SKIPSPIN > nooptions DEADLKRES > nooptions USB_DEBUG > > > root at rpi3 > :/usr/src# make -j1 buildkernel KERNCONF=RPI3 > > [...] [Like a answered in freebsd-arm . . .] Bugzilla 220125 (from over a year ago) is a non-fixed report about this for the likes of: make kernel-toolchain buildkernel Over the time since then the workaround was to use: make buildworld buildkernel buildworld put the needed stdint.h in place, kernel-toolchain did not. If kernel-toolchain was in use, then the recent bugzilla 229702 and this exchange is a duplicate. If buildworld was in use then 229702 and this exchange is new. [Added note . . .] It seems from the quoted material that neither kernel-toolchain nor build world was done before buildkernel . My understanding is that the intent is that one or the other be done first. (But for aarch64 currently only buildworld works.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
