Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C
FreeBSD User wrote on Date: Thu, 09 Mar 2023 08:42:44 UTC : > Having set > > WITHOUT_CROSS_COMPILER=YES > WITHOUT_SYSTEM_COMPILER=YES > WITHOUT_SYSTEM_LINKER=YES > This is contradictory: a mix of a setting that first tells it to not build some things and then some settings telling it to build some of those same things. WITHOUT_CROSS_COMPILER Do not build any cross compiler in the cross-tools stage of buildworld. . . . When set, it enforces these options: WITHOUT_CLANG_BOOTSTRAP [Do not build the Clang C/C++ compiler during the bootstrap phase of the build.] WITHOUT_ELFTOOLCHAIN_BOOTSTRAP [Do not build ELF Tool Chain tools (addr2line, nm, size, strings and strip) as part of the bootstrap process.] WITHOUT_LLD_BOOTSTRAP [Do not build the LLD linker during the bootstrap phase of the build.] But, using Ed's new wording suggestion: WITHOUT_SYSTEM_COMPILER Build a cross-compiler during the build bootstrap phase, rather than opportunistically using the host's compiler. WITHOUT_SYSTEM_LINKER Build a cross-linker during the build bootstrap phase, rather than opportunistically using the host's linker. May be such a build attempt should abort with a message about the lack of uniformity in the criteria? Side note: > ld: error: args.o: Opaque pointers are only supported in -opaque-pointers > mode (Producer: > 'LLVM15.0.7' Reader: 'LLVM 14.0.5') cc: error: linker command failed with > exit code 1 (use -v > to see invocation) *** [gh-bc] Error code 1 seems to indicate that llvm15 was used to produce a file at some point but later llvm14 was used to process the file. === Mark Millard marklmi at yahoo.com
Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C
Am Wed, 8 Mar 2023 12:13:49 +0100
tue...@freebsd.org schrieb:
> > On 8. Mar 2023, at 11:42, FreeBSD User wrote:
> >
> > Am Wed, 8 Mar 2023 11:28:11 +0100
> > Dimitry Andric schrieb:
> >
> >> On 8 Mar 2023, at 11:19, FreeBSD User wrote:
> >> ...
> >>> But I don't understand why the make environment is trying to compile a
> >>> piece of code that
> >>> is disabled via "nodevice" as shown in my initial report herein:
> >>>
> >>> [...]
> >>> src/sys/dev/an/if_an_pci.c:143:1: error: a function definition without a
> >>> prototype is
> >>> deprecated in all versions of C and is not supported in C2x
> >>> [-Werror,-Wdeprecated-non-prototype]
> >>> [...]
> >>
> >> The "nodevice" is for your custom kernel configuration, but as far as I
> >> can see an(4) is still built as a module, see sys/modules/Makefile:
> >>
> >> ...
> >> .if ${MACHINE_CPUARCH} == "i386" || ${MACHINE_CPUARCH} == "amd64"
> >> _agp= agp
> >> _an=an
> >>
> >> -Dimitry
> >>
> >
> > Oh, I'm sorry,
> > my fault in logic!
> >
> > Is there a "knob" to explicitely disable that specific module from being
> > built from a
> > point of view of a user like me (not touching the base build system)?
> Use
> WITHOUT_MODULES=an
> in
> /etc/make.conf
>
> Best regards
> Michael
> >
> > --
> > O. Hartmann
>
>
With setting
WITHOUT_SYSTEM_COMPILER=YES
WITHOUT_SYSTEM_LINKER=YES
in CONF_BUILD and CONF_WORLD and WITHOUT_CROSS_COMPILER=YES commented out (not
building/not
cross compile?) and a fresh and clean start of the build, I run into
[...]
ld: error: args.o: Opaque pointers are only supported in -opaque-pointers mode
(Producer:
'LLVM15.0.7' Reader: 'LLVM 14.0.5') cc: error: linker command failed with exit
code 1 (use -v
to see invocation) *** [gh-bc] Error code 1
[...]
That seems to be the issue mostly discussed herein regarding LLVM14 and LLVM15.
Having set
WITHOUT_CROSS_COMPILER=YES
WITHOUT_SYSTEM_COMPILER=YES
WITHOUT_SYSTEM_LINKER=YES
WITHOUT_MODULES=an
in both CONF_BUILD and CONF_WORLD (I do so because I do not know which one is
really affecting
the build), I receive the reported compiling error problem in if_an.c.
Setting WITHOUT_MODULES=an in both CONF_BUILD and CONF_WORLD (nanoBSD!) doesn't
seem to have
any effect.
Regardfs,
oh
--
O. Hartmann
Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C
> On Mar 8, 2023, at 10:26 PM, Ed Maste wrote: > > On Thu, 2 Mar 2023 at 05:14, Dimitry Andric wrote: >> >> WITHOUT_SYSTEM_COMPILER >> Do not opportunistically skip building a cross-compiler during >> the bootstrap phase of the build. Normally, if the currently > ... >> I find the double negative phrasing "do not skip" always confusing. But >> the logic is normally: > > Yes, it's confusing -- perhaps we could rewrite it as something like > "Build a cross-compiler during the build bootstrap phase, rather than > opportunistically using the host's compiler." > +1 for that.
Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C
On Thu, 2 Mar 2023 at 05:14, Dimitry Andric wrote: > > WITHOUT_SYSTEM_COMPILER > Do not opportunistically skip building a cross-compiler during > the bootstrap phase of the build. Normally, if the currently ... > I find the double negative phrasing "do not skip" always confusing. But > the logic is normally: Yes, it's confusing -- perhaps we could rewrite it as something like "Build a cross-compiler during the build bootstrap phase, rather than opportunistically using the host's compiler."
Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C
> On 8. Mar 2023, at 11:42, FreeBSD User wrote:
>
> Am Wed, 8 Mar 2023 11:28:11 +0100
> Dimitry Andric schrieb:
>
>> On 8 Mar 2023, at 11:19, FreeBSD User wrote:
>> ...
>>> But I don't understand why the make environment is trying to compile a
>>> piece of code that
>>> is disabled via "nodevice" as shown in my initial report herein:
>>>
>>> [...]
>>> src/sys/dev/an/if_an_pci.c:143:1: error: a function definition without a
>>> prototype is
>>> deprecated in all versions of C and is not supported in C2x
>>> [-Werror,-Wdeprecated-non-prototype]
>>> [...]
>>
>> The "nodevice" is for your custom kernel configuration, but as far as I
>> can see an(4) is still built as a module, see sys/modules/Makefile:
>>
>> ...
>> .if ${MACHINE_CPUARCH} == "i386" || ${MACHINE_CPUARCH} == "amd64"
>> _agp= agp
>> _an=an
>>
>> -Dimitry
>>
>
> Oh, I'm sorry,
> my fault in logic!
>
> Is there a "knob" to explicitely disable that specific module from being
> built from a point of
> view of a user like me (not touching the base build system)?
Use
WITHOUT_MODULES=an
in
/etc/make.conf
Best regards
Michael
>
> --
> O. Hartmann
Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C
Am Wed, 8 Mar 2023 11:28:11 +0100
Dimitry Andric schrieb:
> On 8 Mar 2023, at 11:19, FreeBSD User wrote:
> ...
> > But I don't understand why the make environment is trying to compile a
> > piece of code that
> > is disabled via "nodevice" as shown in my initial report herein:
> >
> > [...]
> > src/sys/dev/an/if_an_pci.c:143:1: error: a function definition without a
> > prototype is
> > deprecated in all versions of C and is not supported in C2x
> > [-Werror,-Wdeprecated-non-prototype]
> > [...]
>
> The "nodevice" is for your custom kernel configuration, but as far as I
> can see an(4) is still built as a module, see sys/modules/Makefile:
>
> ...
> .if ${MACHINE_CPUARCH} == "i386" || ${MACHINE_CPUARCH} == "amd64"
> _agp= agp
> _an=an
>
> -Dimitry
>
Oh, I'm sorry,
my fault in logic!
Is there a "knob" to explicitely disable that specific module from being built
from a point of
view of a user like me (not touching the base build system)?
--
O. Hartmann
pgpoewHqtwo_9.pgp
Description: OpenPGP digital signature
Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C
On 8 Mar 2023, at 11:19, FreeBSD User wrote:
...
> But I don't understand why the make environment is trying to compile a piece
> of code that is
> disabled via "nodevice" as shown in my initial report herein:
>
> [...]
> src/sys/dev/an/if_an_pci.c:143:1: error: a function definition without a
> prototype is
> deprecated in all versions of C and is not supported in C2x
> [-Werror,-Wdeprecated-non-prototype]
> [...]
The "nodevice" is for your custom kernel configuration, but as far as I
can see an(4) is still built as a module, see sys/modules/Makefile:
...
.if ${MACHINE_CPUARCH} == "i386" || ${MACHINE_CPUARCH} == "amd64"
_agp= agp
_an=an
-Dimitry
signature.asc
Description: Message signed with OpenPGP
Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C
Am Thu, 2 Mar 2023 11:13:51 +0100 Dimitry Andric schrieb: > On 2 Mar 2023, at 06:41, FreeBSD User wrote: > > > > Am Mon, 27 Feb 2023 23:46:21 +0100 > > Dimitry Andric schrieb: > ... > > > > I tried to find some documentation on my CURRENT host regarding > > "WITH_SYSTEM_COMPILER". > > None found via man src.conf, nor via make make.conf. Please delegate me to > > some place > > where I can find such infos. > > Ah I was confused, WITH_SYSTEM_COMPILER is actually the default, and it > means that you want to skip building the bootstrap compiler, and just > use the host compiler. The src.conf(5) man page documents the inverse > settings instead: > > WITHOUT_SYSTEM_COMPILER > Do not opportunistically skip building a cross-compiler during > the bootstrap phase of the build. Normally, if the currently > installed compiler matches the planned bootstrap compiler type > and revision, then it will not be built. This does not prevent a > compiler from being built for installation though, only for > building one for the build itself. The WITHOUT_CLANG option > controls that. > > WITHOUT_SYSTEM_LINKER > Do not opportunistically skip building a cross-linker during the > bootstrap phase of the build. Normally, if the currently > installed linker matches the planned bootstrap linker type and > revision, then it will not be built. This does not prevent a > linker from being built for installation though, only for > building one for the build itself. The WITHOUT_LLD option > controls that. > > This option is only relevant when WITH_LLD_BOOTSTRAP is set. > > I find the double negative phrasing "do not skip" always confusing. But > the logic is normally: > > * The early phase of buildworld retrieves the versions of your host's > compiler and linker > * It compares it against the versions in the source tree > * If the host compiler and linker are deemed "good enough", they are > used as-is > * If the host compiler or linker are not suitable, the compiler or > linker are bootstrapped from the source tree > > But WITH_SYSTEM_COMPILER turns off all these checks and forces it to use > the host compiler, which might or might not work, depending on the > circumstances. You may have to use NO_WERROR or other tricks. > > > ... > >> The safest solution is to let cross-tools do its thing, which will check > >> the host compiler, and automatically build an appropriate version of the > >> compiler and linker for the stable branch, if required. > > > > I had a misunderstanding in the terminus "cross compiling", I check now the > > build with this > > option set to be enabled. > > Yes, this is a bit confusing, but in fact it *can* be a real cross > compiler, if you are targeting another architecture, for example doing > "make buildworld TARGET=arm64" from an x86_64 host. > > And of course if you are building natively, it is 'just' a regular > bootstrap compiler. > > -Dimitry > As it turns out, I already used in both sections CONF_BUILD= CONF_WORLD= of nanoBSD's configuration WITHOUT_SYSTEM_COMPILER and added also WITHOUT_SYSTEM_LINKER to be safe. But I don't understand why the make environment is trying to compile a piece of code that is disabled via "nodevice" as shown in my initial report herein: [...] src/sys/dev/an/if_an_pci.c:143:1: error: a function definition without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype] [...] From my point of view neither compiler suite, LLVM14 or LLVM15, should have picked up the if_an driver so far. Or do I miss something here? If so, my apologys. Kind regards Oliver -- O. Hartmann pgpqQrUscz3_U.pgp Description: OpenPGP digital signature
Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C
Dimitry Andric wrote on Date: Thu, 02 Mar 2023 10:13:51 UTC : > On 2 Mar 2023, at 06:41, FreeBSD User wrote: >> >> Am Mon, 27 Feb 2023 23:46:21 +0100 >> Dimitry Andric schrieb: > ... >> >> I tried to find some documentation on my CURRENT host regarding >> "WITH_SYSTEM_COMPILER". None >> found via man src.conf, nor via make make.conf. Please delegate me to some >> place where I can >> find such infos. > > Ah I was confused, WITH_SYSTEM_COMPILER is actually the default, and it > means that you want to skip building the bootstrap compiler, and just > use the host compiler. If allowed?: Having a 13.* build 14.0 does not allow skipping building the bootstrap compiler for buildworld or kernel-toolchain (for the same processor family), for example, if I understand right. In other words, one does not have to explicitly use WITHOUT_SYSTEM_COMPILER for such FreeBSD version- increase builds, even for self-hosted builds: the default works and is WITH_SYSTEM_COMPILER . > The src.conf(5) man page documents the inverse > settings instead: > > WITHOUT_SYSTEM_COMPILER > Do not opportunistically skip building a cross-compiler during > the bootstrap phase of the build. Normally, if the currently > installed compiler matches the planned bootstrap compiler type > and revision, then it will not be built. This does not prevent a > compiler from being built for installation though, only for > building one for the build itself. The WITHOUT_CLANG option > controls that. Explicit WITHOUT_SYSTEM_COMPILER usage is unconditional, unlike WITH_SYSTEM_COMPILER usage (implicit or explicit) depending on both the FreeBSD version differences and the processor family relationship, if I understand right. > WITHOUT_SYSTEM_LINKER > Do not opportunistically skip building a cross-linker during the > bootstrap phase of the build. Normally, if the currently > installed linker matches the planned bootstrap linker type and > revision, then it will not be built. This does not prevent a > linker from being built for installation though, only for > building one for the build itself. The WITHOUT_LLD option > controls that. > > This option is only relevant when WITH_LLD_BOOTSTRAP is set. > > I find the double negative phrasing "do not skip" always confusing. But > the logic is normally: > > * The early phase of buildworld retrieves the versions of your host's > compiler and linker > * It compares it against the versions in the source tree > * If the host compiler and linker are deemed "good enough", they are > used as-is (So I've effectively noted some of the not "good enough" criteria above.) > * If the host compiler or linker are not suitable, the compiler or > linker are bootstrapped from the source tree > > But WITH_SYSTEM_COMPILER turns off all these checks and forces it to use > the host compiler, Are you saying that an implicit WITH_SYSTEM_COMPILER (no explicit WITHOUT_SYSTEM_COMPILER either) works differently than an explicit WITH_SYSTEM_COMPILER for FreeBSD version transitions? If so, I need to correct my expectations. > which might or might not work, depending on the > circumstances. You may have to use NO_WERROR or other tricks. > > > ... >>> The safest solution is to let cross-tools do its thing, which will check >>> the host compiler, and automatically build an appropriate version of the >>> compiler and linker for the stable branch, if required. >> >> I had a misunderstanding in the terminus "cross compiling", I check now the >> build with this >> option set to be enabled. > > Yes, this is a bit confusing, but in fact it *can* be a real cross > compiler, if you are targeting another architecture, for example doing > "make buildworld TARGET=arm64" from an x86_64 host. In my view/expectation the differences between the Target defaults for the likes of: Target: x86_64-unknown-freebsd13.1 vs: Target: x86_64-unknown-freebsd13.2 vs: Target: x86_64-unknown-freebsd14.0 system compilers is enough to make having FreeBSD from earlier in the list above build targeting a later one in the list as a "bootstrap/cross compile": in other words, either x86_64 vs. not or freebsdA.B vs. freebsdX.Y differences count in the criteria and either changing for FROM->TO ends up needing a bootstrap/cross compiler. > > And of course if you are building natively, it is 'just' a regular > bootstrap compiler. Not for freebsdA.B -> freebsdX.Y transitions, based on changes in default targets (and other details that may sometimes implicitly go with that differing default Target being used in the new compiler). === Mark Millard marklmi at yahoo.com
Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C
Am Thu, 2 Mar 2023 11:13:51 +0100 Dimitry Andric schrieb: > On 2 Mar 2023, at 06:41, FreeBSD User wrote: > > > > Am Mon, 27 Feb 2023 23:46:21 +0100 > > Dimitry Andric schrieb: > ... > > > > I tried to find some documentation on my CURRENT host regarding > > "WITH_SYSTEM_COMPILER". > > None found via man src.conf, nor via make make.conf. Please delegate me to > > some place > > where I can find such infos. > > Ah I was confused, WITH_SYSTEM_COMPILER is actually the default, and it > means that you want to skip building the bootstrap compiler, and just > use the host compiler. The src.conf(5) man page documents the inverse > settings instead: > > WITHOUT_SYSTEM_COMPILER > Do not opportunistically skip building a cross-compiler during > the bootstrap phase of the build. Normally, if the currently > installed compiler matches the planned bootstrap compiler type > and revision, then it will not be built. This does not prevent a > compiler from being built for installation though, only for > building one for the build itself. The WITHOUT_CLANG option > controls that. > > WITHOUT_SYSTEM_LINKER > Do not opportunistically skip building a cross-linker during the > bootstrap phase of the build. Normally, if the currently > installed linker matches the planned bootstrap linker type and > revision, then it will not be built. This does not prevent a > linker from being built for installation though, only for > building one for the build itself. The WITHOUT_LLD option > controls that. > > This option is only relevant when WITH_LLD_BOOTSTRAP is set. > > I find the double negative phrasing "do not skip" always confusing. But > the logic is normally: > > * The early phase of buildworld retrieves the versions of your host's > compiler and linker > * It compares it against the versions in the source tree > * If the host compiler and linker are deemed "good enough", they are > used as-is > * If the host compiler or linker are not suitable, the compiler or > linker are bootstrapped from the source tree > > But WITH_SYSTEM_COMPILER turns off all these checks and forces it to use > the host compiler, which might or might not work, depending on the > circumstances. You may have to use NO_WERROR or other tricks. Thank you for the explanation. I read the man page of src.conf in a haste solving my problem and did not spend much time in reading carefully. I'd appreciate to see YOUR explanation in the official man page, or at least a more non-logical-twisted version. ;-) oh > > > ... > >> The safest solution is to let cross-tools do its thing, which will check > >> the host compiler, and automatically build an appropriate version of the > >> compiler and linker for the stable branch, if required. > > > > I had a misunderstanding in the terminus "cross compiling", I check now the > > build with this > > option set to be enabled. > > Yes, this is a bit confusing, but in fact it *can* be a real cross > compiler, if you are targeting another architecture, for example doing > "make buildworld TARGET=arm64" from an x86_64 host. > > And of course if you are building natively, it is 'just' a regular > bootstrap compiler. > > -Dimitry > -- O. Hartmann pgpo5n59s79UP.pgp Description: OpenPGP digital signature
Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C
[Seems to have gotten stuck in my Outbox. Trying again.] Dimitry Andric wrote on Date: Thu, 02 Mar 2023 10:13:51 UTC : > On 2 Mar 2023, at 06:41, FreeBSD User wrote: >> >> Am Mon, 27 Feb 2023 23:46:21 +0100 >> Dimitry Andric schrieb: > ... >> >> I tried to find some documentation on my CURRENT host regarding >> "WITH_SYSTEM_COMPILER". None >> found via man src.conf, nor via make make.conf. Please delegate me to some >> place where I can >> find such infos. > > Ah I was confused, WITH_SYSTEM_COMPILER is actually the default, and it > means that you want to skip building the bootstrap compiler, and just > use the host compiler. If allowed?: Having a 13.* build 14.0 does not allow skipping building the bootstrap compiler for buildworld or kernel-toolchain (for the same processor family), for example, if I understand right. In other words, one does not have to explicitly use WITHOUT_SYSTEM_COMPILER for such FreeBSD version- increase builds, even for self-hosted builds: the default works and is WITH_SYSTEM_COMPILER . > The src.conf(5) man page documents the inverse > settings instead: > > WITHOUT_SYSTEM_COMPILER > Do not opportunistically skip building a cross-compiler during > the bootstrap phase of the build. Normally, if the currently > installed compiler matches the planned bootstrap compiler type > and revision, then it will not be built. This does not prevent a > compiler from being built for installation though, only for > building one for the build itself. The WITHOUT_CLANG option > controls that. Explicit WITHOUT_SYSTEM_COMPILER usage is unconditional, unlike WITH_SYSTEM_COMPILER usage (implicit or explicit) depending on both the FreeBSD version differences and the processor family relationship, if I understand right. > WITHOUT_SYSTEM_LINKER > Do not opportunistically skip building a cross-linker during the > bootstrap phase of the build. Normally, if the currently > installed linker matches the planned bootstrap linker type and > revision, then it will not be built. This does not prevent a > linker from being built for installation though, only for > building one for the build itself. The WITHOUT_LLD option > controls that. > > This option is only relevant when WITH_LLD_BOOTSTRAP is set. > > I find the double negative phrasing "do not skip" always confusing. But > the logic is normally: > > * The early phase of buildworld retrieves the versions of your host's > compiler and linker > * It compares it against the versions in the source tree > * If the host compiler and linker are deemed "good enough", they are > used as-is (So I've effectively noted some of the not "good enough" criteria above.) > * If the host compiler or linker are not suitable, the compiler or > linker are bootstrapped from the source tree > > But WITH_SYSTEM_COMPILER turns off all these checks and forces it to use > the host compiler, Are you saying that an implicit WITH_SYSTEM_COMPILER (no explicit WITHOUT_SYSTEM_COMPILER either) works differently than an explicit WITH_SYSTEM_COMPILER for FreeBSD version transitions? If so, I need to correct my expectations. > which might or might not work, depending on the > circumstances. You may have to use NO_WERROR or other tricks. > > > ... >>> The safest solution is to let cross-tools do its thing, which will check >>> the host compiler, and automatically build an appropriate version of the >>> compiler and linker for the stable branch, if required. >> >> I had a misunderstanding in the terminus "cross compiling", I check now the >> build with this >> option set to be enabled. > > Yes, this is a bit confusing, but in fact it *can* be a real cross > compiler, if you are targeting another architecture, for example doing > "make buildworld TARGET=arm64" from an x86_64 host. In my view/expectation the differences between the Target defaults for the likes of: Target: x86_64-unknown-freebsd13.1 vs: Target: x86_64-unknown-freebsd13.2 vs: Target: x86_64-unknown-freebsd14.0 system compilers is enough to make having FreeBSD from earlier in the list above build targeting a later one in the list as a "bootstrap/cross compile": in other words, either x86_64 vs. not or freebsdA.B vs. freebsdX.Y differences count in the criteria and either changing for FROM->TO ends up needing a bootstrap/cross compiler. > > And of course if you are building natively, it is 'just' a regular > bootstrap compiler. Not for freebsdA.B -> freebsdX.Y transitions, based on changes in default targets (and other details that may sometimes implicitly go with that differing default Target being used in the new compiler). === Mark Millard marklmi at yahoo.com
Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C
On 2 Mar 2023, at 06:41, FreeBSD User wrote: > > Am Mon, 27 Feb 2023 23:46:21 +0100 > Dimitry Andric schrieb: ... > > I tried to find some documentation on my CURRENT host regarding > "WITH_SYSTEM_COMPILER". None > found via man src.conf, nor via make make.conf. Please delegate me to some > place where I can > find such infos. Ah I was confused, WITH_SYSTEM_COMPILER is actually the default, and it means that you want to skip building the bootstrap compiler, and just use the host compiler. The src.conf(5) man page documents the inverse settings instead: WITHOUT_SYSTEM_COMPILER Do not opportunistically skip building a cross-compiler during the bootstrap phase of the build. Normally, if the currently installed compiler matches the planned bootstrap compiler type and revision, then it will not be built. This does not prevent a compiler from being built for installation though, only for building one for the build itself. The WITHOUT_CLANG option controls that. WITHOUT_SYSTEM_LINKER Do not opportunistically skip building a cross-linker during the bootstrap phase of the build. Normally, if the currently installed linker matches the planned bootstrap linker type and revision, then it will not be built. This does not prevent a linker from being built for installation though, only for building one for the build itself. The WITHOUT_LLD option controls that. This option is only relevant when WITH_LLD_BOOTSTRAP is set. I find the double negative phrasing "do not skip" always confusing. But the logic is normally: * The early phase of buildworld retrieves the versions of your host's compiler and linker * It compares it against the versions in the source tree * If the host compiler and linker are deemed "good enough", they are used as-is * If the host compiler or linker are not suitable, the compiler or linker are bootstrapped from the source tree But WITH_SYSTEM_COMPILER turns off all these checks and forces it to use the host compiler, which might or might not work, depending on the circumstances. You may have to use NO_WERROR or other tricks. ... >> The safest solution is to let cross-tools do its thing, which will check >> the host compiler, and automatically build an appropriate version of the >> compiler and linker for the stable branch, if required. > > I had a misunderstanding in the terminus "cross compiling", I check now the > build with this > option set to be enabled. Yes, this is a bit confusing, but in fact it *can* be a real cross compiler, if you are targeting another architecture, for example doing "make buildworld TARGET=arm64" from an x86_64 host. And of course if you are building natively, it is 'just' a regular bootstrap compiler. -Dimitry signature.asc Description: Message signed with OpenPGP
Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C
Am Mon, 27 Feb 2023 23:46:21 +0100
Dimitry Andric schrieb:
> On 27 Feb 2023, at 22:23, Paul Mather wrote:
> >
> > On Feb 27, 2023, at 2:57 PM, Dimitry Andric wrote:
> >
> >> On 27 Feb 2023, at 19:19, FreeBSD User wrote:
> >>>
> >>> Running recent CURRENT as host (FreeBSD 14.0-CURRENT #23
> >>> main-n261147-b8bb73ab724b: Sun
> >>> Feb 26 17:39:38 CET 2023 amd64), and nanoBSD (recent 13-STABLE, git
> >>> stable/13).
> >>>
> >>> Building an appliance based on 13-STABLE sources, a customized kernel via
> >>> nanoBSD, since
> >>> a couple of weeks for now building the sources fails in kernel sources:
> >>>
> >>> [...]
> >>> --- modules-all ---
> >>> --- all_subdir_an ---
> >>> /pool/home/ohartmann/Projects/router/router/apu2c4/src/sys/dev/an/if_an_pci.c:143:1:
> >>> error: a function definition without a prototype is deprecated in all
> >>> versions of C and
> >>> is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
> >>> [..]
> >>>
> >>> Disabling all wireless options in the kernel config starts dropping
> >>> errors of a similar
> >>> kind on other kernel places.
> >>>
> >>> Compiling on FBSD 13-STABLE seems to be all right.
> >>>
> >>> Can this be fixed. please? What causes the error and how can this be
> >>> resolved if the
> >>> subtree of FreeBSD's sources is a submodule?
> >>
> >> Not sure what you mean with "subtree is a submodule", but this is likely
> >> caused by skipping the cross-tools stage somehow. Do you have any
> >> specific make.conf or src.conf settings for that?
> >
> >
> > I got bitten by this recently. In my case, it was Poudriere (running on
> > 14-CURRENT)
> > trying to build a 13-STABLE jail. The Poudriere jail's "src.conf" was
> > taken from the
> > actual system for which Poudriere builds packages. It had (amongst others)
> > these two
> > options:
> >
> > WITH_SYSTEM_COMPILER=yes
> > WITHOUT_CROSS_COMPILER=yes
> >
> >
> > When I commented these out in the jail-src.conf Poudriere file the jail
> > built correctly.
> >
> > I figure the system built fine because its system compiler is LLVM 14.x.
> > The Poudriere
> > system compiler is LLVM 15.x, which has the breaking change wrt. old-style
> > prototypes.
Hello,
I tried to find some documentation on my CURRENT host regarding
"WITH_SYSTEM_COMPILER". None
found via man src.conf, nor via make make.conf. Please delegate me to some
place where I can
find such infos.
>
> Yes, that is what I suspected in Oliver's case: if you skip the
> cross-tools stage in a buildworld of stable/13 on a 14-CURRENT host, by
> setting WITH_SYSTEM_COMPILER, you are bound to run into compilation
> errors that have been fixed in 14-CURRENT, but not yet MFC'd.
From nanoBSD's perspective, all relevant build config files are merged into a
huge file
containing three elementary sections,
CONF_BUILD
CONF_INSTALL
CONF_WORLD
in neither of them I had defined "WITH_SYSTEM_COMPILER=YES" in any way, but I
had configured
in both CONF_INSTALL and CONF_WORLD "WITHOUT_CROSS_COMPILER=YES". I deleted
that knob for now
from "CONF_WORLD" and left it in CONF_INSTALL ("... Options to put in make.conf
during
installworld only ...").
>
> The safest solution is to let cross-tools do its thing, which will check
> the host compiler, and automatically build an appropriate version of the
> compiler and linker for the stable branch, if required.
I had a misunderstanding in the terminus "cross compiling", I check now the
build with this
option set to be enabled.
>
> That said, I will be merging clang 15.0.7 and a bunch of other things
> that should solve all these errors to stable/13 at some point, but not
> before the 13.2-RELEASE is out. This is to avoid making life more
> difficult for our release engineering team.
>
> -Dimitry
>
Thank you for the efforts,
Oliver
--
O. Hartmann
pgpw_vAxYhaNd.pgp
Description: OpenPGP digital signature
Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C
On Mon, Feb 27, 2023 at 3:46 PM Dimitry Andric wrote: > On 27 Feb 2023, at 22:23, Paul Mather wrote: > > > > On Feb 27, 2023, at 2:57 PM, Dimitry Andric wrote: > > > >> On 27 Feb 2023, at 19:19, FreeBSD User wrote: > >>> > >>> Running recent CURRENT as host (FreeBSD 14.0-CURRENT #23 > main-n261147-b8bb73ab724b: Sun Feb 26 > >>> 17:39:38 CET 2023 amd64), and nanoBSD (recent 13-STABLE, git > stable/13). > >>> > >>> Building an appliance based on 13-STABLE sources, a customized kernel > via nanoBSD, since a > >>> couple of weeks for now building the sources fails in kernel sources: > >>> > >>> [...] > >>> --- modules-all --- > >>> --- all_subdir_an --- > >>> > /pool/home/ohartmann/Projects/router/router/apu2c4/src/sys/dev/an/if_an_pci.c:143:1: > error: a > >>> function definition without a prototype is deprecated in all versions > of C and is not > >>> supported in C2x [-Werror,-Wdeprecated-non-prototype] > >>> [..] > >>> > >>> Disabling all wireless options in the kernel config starts dropping > errors of a similar kind > >>> on other kernel places. > >>> > >>> Compiling on FBSD 13-STABLE seems to be all right. > >>> > >>> Can this be fixed. please? What causes the error and how can this be > resolved if the subtree > >>> of FreeBSD's sources is a submodule? > >> > >> Not sure what you mean with "subtree is a submodule", but this is likely > >> caused by skipping the cross-tools stage somehow. Do you have any > >> specific make.conf or src.conf settings for that? > > > > > > I got bitten by this recently. In my case, it was Poudriere (running on > 14-CURRENT) trying to build a 13-STABLE jail. The Poudriere jail's > "src.conf" was taken from the actual system for which Poudriere builds > packages. It had (amongst others) these two options: > > > > WITH_SYSTEM_COMPILER=yes > > WITHOUT_CROSS_COMPILER=yes > > > > > > When I commented these out in the jail-src.conf Poudriere file the jail > built correctly. > > > > I figure the system built fine because its system compiler is LLVM > 14.x. The Poudriere system compiler is LLVM 15.x, which has the breaking > change wrt. old-style prototypes. > > Yes, that is what I suspected in Oliver's case: if you skip the > cross-tools stage in a buildworld of stable/13 on a 14-CURRENT host, by > setting WITH_SYSTEM_COMPILER, you are bound to run into compilation > errors that have been fixed in 14-CURRENT, but not yet MFC'd. > > The safest solution is to let cross-tools do its thing, which will check > the host compiler, and automatically build an appropriate version of the > compiler and linker for the stable branch, if required. > > That said, I will be merging clang 15.0.7 and a bunch of other things > that should solve all these errors to stable/13 at some point, but not > before the 13.2-RELEASE is out. This is to avoid making life more > difficult for our release engineering team. > In the meantime, I think you can disable -Werror with MK_WERROR=no in one of the nanobsd config file. The warnings are significantly less relevant for stable/xx because they are not likely to inspire people to fix them like they would on main. And to fix these, you'd need to merge the fixes from head, or at least the neutering of large classes of errors like we had (still have?) in main Warner > -Dimitry > >
Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C
On 27 Feb 2023, at 22:23, Paul Mather wrote: > > On Feb 27, 2023, at 2:57 PM, Dimitry Andric wrote: > >> On 27 Feb 2023, at 19:19, FreeBSD User wrote: >>> >>> Running recent CURRENT as host (FreeBSD 14.0-CURRENT #23 >>> main-n261147-b8bb73ab724b: Sun Feb 26 >>> 17:39:38 CET 2023 amd64), and nanoBSD (recent 13-STABLE, git stable/13). >>> >>> Building an appliance based on 13-STABLE sources, a customized kernel via >>> nanoBSD, since a >>> couple of weeks for now building the sources fails in kernel sources: >>> >>> [...] >>> --- modules-all --- >>> --- all_subdir_an --- >>> /pool/home/ohartmann/Projects/router/router/apu2c4/src/sys/dev/an/if_an_pci.c:143:1: >>> error: a >>> function definition without a prototype is deprecated in all versions of C >>> and is not >>> supported in C2x [-Werror,-Wdeprecated-non-prototype] >>> [..] >>> >>> Disabling all wireless options in the kernel config starts dropping errors >>> of a similar kind >>> on other kernel places. >>> >>> Compiling on FBSD 13-STABLE seems to be all right. >>> >>> Can this be fixed. please? What causes the error and how can this be >>> resolved if the subtree >>> of FreeBSD's sources is a submodule? >> >> Not sure what you mean with "subtree is a submodule", but this is likely >> caused by skipping the cross-tools stage somehow. Do you have any >> specific make.conf or src.conf settings for that? > > > I got bitten by this recently. In my case, it was Poudriere (running on > 14-CURRENT) trying to build a 13-STABLE jail. The Poudriere jail's > "src.conf" was taken from the actual system for which Poudriere builds > packages. It had (amongst others) these two options: > > WITH_SYSTEM_COMPILER=yes > WITHOUT_CROSS_COMPILER=yes > > > When I commented these out in the jail-src.conf Poudriere file the jail built > correctly. > > I figure the system built fine because its system compiler is LLVM 14.x. The > Poudriere system compiler is LLVM 15.x, which has the breaking change wrt. > old-style prototypes. Yes, that is what I suspected in Oliver's case: if you skip the cross-tools stage in a buildworld of stable/13 on a 14-CURRENT host, by setting WITH_SYSTEM_COMPILER, you are bound to run into compilation errors that have been fixed in 14-CURRENT, but not yet MFC'd. The safest solution is to let cross-tools do its thing, which will check the host compiler, and automatically build an appropriate version of the compiler and linker for the stable branch, if required. That said, I will be merging clang 15.0.7 and a bunch of other things that should solve all these errors to stable/13 at some point, but not before the 13.2-RELEASE is out. This is to avoid making life more difficult for our release engineering team. -Dimitry signature.asc Description: Message signed with OpenPGP
Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C
On Feb 27, 2023, at 2:57 PM, Dimitry Andric wrote: > On 27 Feb 2023, at 19:19, FreeBSD User wrote: >> >> Running recent CURRENT as host (FreeBSD 14.0-CURRENT #23 >> main-n261147-b8bb73ab724b: Sun Feb 26 >> 17:39:38 CET 2023 amd64), and nanoBSD (recent 13-STABLE, git stable/13). >> >> Building an appliance based on 13-STABLE sources, a customized kernel via >> nanoBSD, since a >> couple of weeks for now building the sources fails in kernel sources: >> >> [...] >> --- modules-all --- >> --- all_subdir_an --- >> /pool/home/ohartmann/Projects/router/router/apu2c4/src/sys/dev/an/if_an_pci.c:143:1: >> error: a >> function definition without a prototype is deprecated in all versions of C >> and is not >> supported in C2x [-Werror,-Wdeprecated-non-prototype] >> [..] >> >> Disabling all wireless options in the kernel config starts dropping errors >> of a similar kind >> on other kernel places. >> >> Compiling on FBSD 13-STABLE seems to be all right. >> >> Can this be fixed. please? What causes the error and how can this be >> resolved if the subtree >> of FreeBSD's sources is a submodule? > > Not sure what you mean with "subtree is a submodule", but this is likely > caused by skipping the cross-tools stage somehow. Do you have any > specific make.conf or src.conf settings for that? I got bitten by this recently. In my case, it was Poudriere (running on 14-CURRENT) trying to build a 13-STABLE jail. The Poudriere jail's "src.conf" was taken from the actual system for which Poudriere builds packages. It had (amongst others) these two options: WITH_SYSTEM_COMPILER=yes WITHOUT_CROSS_COMPILER=yes When I commented these out in the jail-src.conf Poudriere file the jail built correctly. I figure the system built fine because its system compiler is LLVM 14.x. The Poudriere system compiler is LLVM 15.x, which has the breaking change wrt. old-style prototypes. Cheers, Paul.
Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C
On Mon, Feb 27, 2023 at 03:40:41PM -0500, Shawn Webb wrote: > On Mon, Feb 27, 2023 at 08:57:19PM +0100, Dimitry Andric wrote: > > On 27 Feb 2023, at 19:19, FreeBSD User wrote: > > > > > > Running recent CURRENT as host (FreeBSD 14.0-CURRENT #23 > > > main-n261147-b8bb73ab724b: Sun Feb 26 > > > 17:39:38 CET 2023 amd64), and nanoBSD (recent 13-STABLE, git stable/13). > > > > > > Building an appliance based on 13-STABLE sources, a customized kernel via > > > nanoBSD, since a > > > couple of weeks for now building the sources fails in kernel sources: > > > > > > [...] > > > --- modules-all --- > > > --- all_subdir_an --- > > > /pool/home/ohartmann/Projects/router/router/apu2c4/src/sys/dev/an/if_an_pci.c:143:1: > > > error: a > > > function definition without a prototype is deprecated in all versions of > > > C and is not > > > supported in C2x [-Werror,-Wdeprecated-non-prototype] > > > [..] > > > > > > Disabling all wireless options in the kernel config starts dropping > > > errors of a similar kind > > > on other kernel places. > > > > > > Compiling on FBSD 13-STABLE seems to be all right. > > > > > > Can this be fixed. please? What causes the error and how can this be > > > resolved if the subtree > > > of FreeBSD's sources is a submodule? > > > > Not sure what you mean with "subtree is a submodule", but this is likely > > caused by skipping the cross-tools stage somehow. Do you have any > > specific make.conf or src.conf settings for that? > > FWIW, HardenedBSD is also impacted by this. We set > WITH_SYSTEM_COMPILER and WITH_SYSTEM_LINKER by default, which I think > might be a contributing factor. The reason for not hitting the error in that particular file in 14-CURRENT is because the an(4) driver was removed by FreeBSD in commit 663b174b5b5387948bfa94131a08f6259d2926cc from 07 June 2021. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C
Am Mon, 27 Feb 2023 20:57:19 +0100 Dimitry Andric schrieb: > On 27 Feb 2023, at 19:19, FreeBSD User wrote: > > > > Running recent CURRENT as host (FreeBSD 14.0-CURRENT #23 > > main-n261147-b8bb73ab724b: Sun > > Feb 26 17:39:38 CET 2023 amd64), and nanoBSD (recent 13-STABLE, git > > stable/13). > > > > Building an appliance based on 13-STABLE sources, a customized kernel via > > nanoBSD, since a > > couple of weeks for now building the sources fails in kernel sources: > > > > [...] > > --- modules-all --- > > --- all_subdir_an --- > > /pool/home/ohartmann/Projects/router/router/apu2c4/src/sys/dev/an/if_an_pci.c:143:1: > > error: a function definition without a prototype is deprecated in all > > versions of C and is > > not supported in C2x [-Werror,-Wdeprecated-non-prototype] > > [..] > > > > Disabling all wireless options in the kernel config starts dropping errors > > of a similar > > kind on other kernel places. > > > > Compiling on FBSD 13-STABLE seems to be all right. > > > > Can this be fixed. please? What causes the error and how can this be > > resolved if the > > subtree of FreeBSD's sources is a submodule? > > Not sure what you mean with "subtree is a submodule", but this is likely > caused by skipping the cross-tools stage somehow. Do you have any > specific make.conf or src.conf settings for that? > > -Dimitry > Using a subtree "./src" withing the tree of our own repository for FreeBSD's sources, it is a git submodule. According to your question about specific src.conf and make.conf - Sometimes I really do not know what NanoBSD or any cross compiling tool is picking up which one: the host's one or the one supposed to control NanoBSD's build. So, the host itself does have a specific /etc/src.conf, make.conf is only about some ports options to apply for the host. For the NanoBSD sources, it is considered one file, a merger of make.conf, src.conf, and yes, those ones or in that case this one is highly customized due to spefici requirements for space reduction. Since that has been in the past a source of evil, I tried also with a "vanilla" setup of this sepcific NanoBSD driven config (the host's src.conf/make.conf has been left untouched) - in other words, deleting it, making a full fledged kernel/base system with all the compiler settings at FreeBSD's default - with the same result as shown above. Can you hint me towards what to look after in specific? Kind regards, Oliver -- O. Hartmann pgpEGWMl2A7GD.pgp Description: OpenPGP digital signature
Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C
On Mon, Feb 27, 2023 at 08:57:19PM +0100, Dimitry Andric wrote: > On 27 Feb 2023, at 19:19, FreeBSD User wrote: > > > > Running recent CURRENT as host (FreeBSD 14.0-CURRENT #23 > > main-n261147-b8bb73ab724b: Sun Feb 26 > > 17:39:38 CET 2023 amd64), and nanoBSD (recent 13-STABLE, git stable/13). > > > > Building an appliance based on 13-STABLE sources, a customized kernel via > > nanoBSD, since a > > couple of weeks for now building the sources fails in kernel sources: > > > > [...] > > --- modules-all --- > > --- all_subdir_an --- > > /pool/home/ohartmann/Projects/router/router/apu2c4/src/sys/dev/an/if_an_pci.c:143:1: > > error: a > > function definition without a prototype is deprecated in all versions of C > > and is not > > supported in C2x [-Werror,-Wdeprecated-non-prototype] > > [..] > > > > Disabling all wireless options in the kernel config starts dropping errors > > of a similar kind > > on other kernel places. > > > > Compiling on FBSD 13-STABLE seems to be all right. > > > > Can this be fixed. please? What causes the error and how can this be > > resolved if the subtree > > of FreeBSD's sources is a submodule? > > Not sure what you mean with "subtree is a submodule", but this is likely > caused by skipping the cross-tools stage somehow. Do you have any > specific make.conf or src.conf settings for that? FWIW, HardenedBSD is also impacted by this. We set WITH_SYSTEM_COMPILER and WITH_SYSTEM_LINKER by default, which I think might be a contributing factor. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C
On 27-02-23 19:19, FreeBSD User wrote: Running recent CURRENT as host (FreeBSD 14.0-CURRENT #23 main-n261147-b8bb73ab724b: Sun Feb 26 17:39:38 CET 2023 amd64), and nanoBSD (recent 13-STABLE, git stable/13). Building an appliance based on 13-STABLE sources, a customized kernel via nanoBSD, since a couple of weeks for now building the sources fails in kernel sources: [...] --- modules-all --- --- all_subdir_an --- /pool/home/ohartmann/Projects/router/router/apu2c4/src/sys/dev/an/if_an_pci.c:143:1: error: a function definition without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype] [..] You need to either fix the C code or find someone else that can fix it.* This is code that ensures that function calls correctly match function definitions using the high tech method of "cross your fingers and hope that it works". This was "fixed" by ANSI C going on for 35 years ago. Ancient code like this is probably safe enough - the finger crossing seems to have worked for a long time. It's no wonder people are clamouring to only use safe languages like Rust for new projects. A+ Paul * well maybe there is a compiler switch like -Wno-sane-person-would-do-this
Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C
On 27 Feb 2023, at 19:19, FreeBSD User wrote: > > Running recent CURRENT as host (FreeBSD 14.0-CURRENT #23 > main-n261147-b8bb73ab724b: Sun Feb 26 > 17:39:38 CET 2023 amd64), and nanoBSD (recent 13-STABLE, git stable/13). > > Building an appliance based on 13-STABLE sources, a customized kernel via > nanoBSD, since a > couple of weeks for now building the sources fails in kernel sources: > > [...] > --- modules-all --- > --- all_subdir_an --- > /pool/home/ohartmann/Projects/router/router/apu2c4/src/sys/dev/an/if_an_pci.c:143:1: > error: a > function definition without a prototype is deprecated in all versions of C > and is not > supported in C2x [-Werror,-Wdeprecated-non-prototype] > [..] > > Disabling all wireless options in the kernel config starts dropping errors of > a similar kind > on other kernel places. > > Compiling on FBSD 13-STABLE seems to be all right. > > Can this be fixed. please? What causes the error and how can this be resolved > if the subtree > of FreeBSD's sources is a submodule? Not sure what you mean with "subtree is a submodule", but this is likely caused by skipping the cross-tools stage somehow. Do you have any specific make.conf or src.conf settings for that? -Dimitry signature.asc Description: Message signed with OpenPGP
