Re: NanoBSD: CURRENT unable to compile 13-STABLE : ld: error: args.o: Opaque pointers are only supported in -opaque-pointers mode (Producer: 'LLVM15.0.7' Reader: 'LLVM 14.0.5')
void wrote on Date: Fri, 31 Mar 2023 13:18:34 UTC : > On Thu, Mar 30, 2023 at 07:30:15PM -0700, Mark Millard wrote: > >Warner Losh wrote on > >Date: Thu, 30 Mar 2023 22:15:38 UTC : > > > >> On Thu, Mar 30, 2023, 3:45 PM void wrote: > >> > >> > On Thu, Mar 30, 2023 at 12:56:53PM -0700, Mark Millard wrote: > >> > > >> > >To my knowledge, FreeBSD has not actively supported newer > >> > >FreeBSD building older FreeBSD across versions. > >> > > >> > Are you sure? I routinely build & run 12.4 and 12-stable bhyve and > >> > poudriere jail instances on -current. > >> > > > >Do you use main's toolchain to do your builds of releng/12.4 > >and stable/12 ? The first time? Their updating builds? As far > >as I can see use of main's toolchain means not using an older > >user space (via/in-a chroot, jail, etc.) to do the builds. > > I don't know in detail about the toolchain. When 12.4 builds on > -current, the screen shows it bootstrapping, and I guess this is for > 12.4. > > The reason I commented on what you wrote was because your assertion > appeared to me[1] to be incorrect, in that logically following on from that > assertion would mean 'don't expect it to work because it's 'not > actively supported' meaning that it's 'unsupported'. > > But I can't contextualise 'actively supported' into 'should work' or > 'expected to work' given Warren's comment about 'best effort basis'. > > I build poudriere jails for 12.4 on -current like so: > > 1. git -C /usr/src checkout releng/12.4 > 2. poudriere jail -c -j 124Ramd64 -J12 -m src=/usr/src -b -v releng/12.4 > > To update: > > 3. git -C /usr/src checkout releng/12.4 > 4. git -C /usr/src pull --ff-only > 5. then I have to delete and build the jail as in [2] otherwise it'll > complain about wrong objectprefix > > is this workflow incorrect? I do my own system builds in a directory tree, such as /usr/obj/DESTDIRs/13_1R-CA72-poud , and then have pourdiere(-devel) null mount such to run its jails in for, in this case, releng/13.1 port building on a main [so: 14] system. So I'd need to investigate some to figure out for sure if there is anything odd about your sequence but the delete and build from scratch I'd expect to automatically do a bootstrap toolchain build and then use that build for the later activity that actually targets releng/12.4 . > >A sequence can be bootstrapped by starting from materials for > >a pre-built release or snapshot of the older user space and > >then update via its internal toolchain. My understanding is > >this is the actively supported way, not building older > >user spaces directly from a newer user space and its > >newer toolchain. > > It appears to me[1] to be building its own toolchain and building within > that. The ports it builds work on the machine it's built for, without > errors about things like ABI etc. I don't do any pre-building, and am > unsure if the poudriere jailbuilding process does anything outside of > the standard build process. > > [1] non-expert in any of this! So it looks to me you are building normal bootstrap toolchains and such via normal procedures. My original note was split in 2 parts: building/using bootstrap toolchains vs. otherwise, with the bulk of the text being just about the "otherwise" case: QUOTE I'm unclear here. Is the goal that a system clang 15+ toolchain can build just the bootstrap toolchain and such that are then used to actually build stable/13? Otherwise I'm unclear on how compatibility with what a system clang 14 toolchain would produce is established. . . . END QUOTE Most anything in the "otherwise" material was not intended to apply to the bootstrap case: very different contexts. By contrast, I was not so worried if building and then using a bootstrap toolchain was the intent (instead of direct use of the newer toolchain for everything). I could not tell which case(s) were the intend coverage for what I was replying to. So, overall, I think that you just went in a different direction than I was trying to go in the "otherwise" part of my original note. === Mark Millard marklmi at yahoo.com
Re: NanoBSD: CURRENT unable to compile 13-STABLE : ld: error: args.o: Opaque pointers are only supported in -opaque-pointers mode (Producer: 'LLVM15.0.7' Reader: 'LLVM 14.0.5')
On Thu, Mar 30, 2023 at 07:30:15PM -0700, Mark Millard wrote: Warner Losh wrote on Date: Thu, 30 Mar 2023 22:15:38 UTC : On Thu, Mar 30, 2023, 3:45 PM void wrote: > On Thu, Mar 30, 2023 at 12:56:53PM -0700, Mark Millard wrote: > > >To my knowledge, FreeBSD has not actively supported newer > >FreeBSD building older FreeBSD across versions. > > Are you sure? I routinely build & run 12.4 and 12-stable bhyve and > poudriere jail instances on -current. > Do you use main's toolchain to do your builds of releng/12.4 and stable/12 ? The first time? Their updating builds? As far as I can see use of main's toolchain means not using an older user space (via/in-a chroot, jail, etc.) to do the builds. I don't know in detail about the toolchain. When 12.4 builds on -current, the screen shows it bootstrapping, and I guess this is for 12.4. The reason I commented on what you wrote was because your assertion appeared to me[1] to be incorrect, in that logically following on from that assertion would mean 'don't expect it to work because it's 'not actively supported' meaning that it's 'unsupported'. But I can't contextualise 'actively supported' into 'should work' or 'expected to work' given Warren's comment about 'best effort basis'. I build poudriere jails for 12.4 on -current like so: 1. git -C /usr/src checkout releng/12.4 2. poudriere jail -c -j 124Ramd64 -J12 -m src=/usr/src -b -v releng/12.4 To update: 3. git -C /usr/src checkout releng/12.4 4. git -C /usr/src pull --ff-only 5. then I have to delete and build the jail as in [2] otherwise it'll complain about wrong objectprefix is this workflow incorrect? A sequence can be bootstrapped by starting from materials for a pre-built release or snapshot of the older user space and then update via its internal toolchain. My understanding is this is the actively supported way, not building older user spaces directly from a newer user space and its newer toolchain. It appears to me[1] to be building its own toolchain and building within that. The ports it builds work on the machine it's built for, without errors about things like ABI etc. I don't do any pre-building, and am unsure if the poudriere jailbuilding process does anything outside of the standard build process. [1] non-expert in any of this! --
Re: NanoBSD: CURRENT unable to compile 13-STABLE : ld: error: args.o: Opaque pointers are only supported in -opaque-pointers mode (Producer: 'LLVM15.0.7' Reader: 'LLVM 14.0.5')
Warner Losh wrote on Date: Thu, 30 Mar 2023 22:15:38 UTC : > On Thu, Mar 30, 2023, 3:45 PM void wrote: > > > On Thu, Mar 30, 2023 at 12:56:53PM -0700, Mark Millard wrote: > > > > >To my knowledge, FreeBSD has not actively supported newer > > >FreeBSD building older FreeBSD across versions. > > > > Are you sure? I routinely build & run 12.4 and 12-stable bhyve and > > poudriere jail instances on -current. > > Looks like I can not avoid also dealing some with "run". I was trying only to deal with "build". I'll get "run" out of the way first. I do not think it is relevant to what I was referencing but that may not have been clear. A somewhat older user-space runs on newer kernel in a supported manor. But for newer user-space running on older kernel there is more risk. Some environments even complain: QUOTE Poudriere version: 3.2.8-23-ga7f8d188 Host OSVERSION: 1400073 Jail OSVERSION: 1400084 Job Id: 01 !!! Jail is newer than host. (Jail: 1400084, Host: 1400073) !!! !!! This is not supported. !!! !!! Host kernel must be same or newer than jail. !!! !!! Expect build failures. !!! END QUOTE Some FreeBSD package builders operate this way much of the time (main package building) and sometimes suffer for it. But it gives a away to discover unexpected ABI/semantics breaks and avoids having to update the server kernels as often. I'll note that building releng/13.* packages do not get the complaint because the Jail user-space is earlier (by version) than the host (the host normally being some main vintage): QUOTE Poudriere version: 3.2.8-23-ga7f8d188 Host OSVERSION: 1400073 Jail OSVERSION: 1301000 Job Id: 01 END QUOTE The Jail uses the older user space and its older toolchain, not the toolchain from the Host (main). The main/Host kernel actively supports this use of the older user space. [This context too can end up with discovering an ABI/semantics break. I was somewhat involved in the discovery of one of these breaks fairly recently for the package builders. Main got an update to avoid 13 and before from running into the problem and the package builders got the updated main kernel so that the later package builds that had the problem would go back to normal. The issue was not a toolchain issue in this case.] How this mixes with "build" in my context . . . I've used poudriere-devel on main [so: 14] to build for stable/13 and releng/13.* but the poudriere jails had and used the older user-spaces and the older user-spaces' toolchains, not the toolchain from main. Similarly, I've used chroot areas on a main system to have areas for stable/13 and for releng/13.* . Again these have the older user spaces and the older user spaces' toolchains in use inside, not use of main's toolchain. (I've not been doing virtual machine activities so I'll stick to referencing things analogous to what I've done.) So, given that much context for reference . . . Do you use main's toolchain to do your builds of releng/12.4 and stable/12 ? The first time? Their updating builds? As far as I can see use of main's toolchain means not using an older user space (via/in-a chroot, jail, etc.) to do the builds. A sequence can be bootstrapped by starting from materials for a pre-built release or snapshot of the older user space and then update via its internal toolchain. My understanding is this is the actively supported way, not building older user spaces directly from a newer user space and its newer toolchain. May be having the chroot/jail/... is a big enough issue that some effort is put to avoiding needing to have a older user space around. But I'm not aware of such and have certainly not done such. (I ignore here various odd things I needed to do when doing my early powerpc* clang related investigations before the PowerMac's died. Such was definitely not in the realm of supported activity.) > It's something we try to keep working... on a best effort basis. I'm not sure if that wording is about "run" vs. "build" vs. both. I was only focused on the user-space and toolchain vintage involved in the build, not about the kernel vintage that code was run under. I worry that my note got taken in a different way than I intended, making interpreting responses messy. === Mark Millard marklmi at yahoo.com
Re: NanoBSD: CURRENT unable to compile 13-STABLE : ld: error: args.o: Opaque pointers are only supported in -opaque-pointers mode (Producer: 'LLVM15.0.7' Reader: 'LLVM 14.0.5')
On Thu, Mar 30, 2023, 3:45 PM void wrote: > On Thu, Mar 30, 2023 at 12:56:53PM -0700, Mark Millard wrote: > > >To my knowledge, FreeBSD has not actively supported newer > >FreeBSD building older FreeBSD across versions. > > Are you sure? I routinely build & run 12.4 and 12-stable bhyve and > poudriere jail instances on -current. > It's something we try to keep working... on a best effort basis. Warner >
Re: NanoBSD: CURRENT unable to compile 13-STABLE : ld: error: args.o: Opaque pointers are only supported in -opaque-pointers mode (Producer: 'LLVM15.0.7' Reader: 'LLVM 14.0.5')
On Thu, Mar 30, 2023 at 12:56:53PM -0700, Mark Millard wrote: To my knowledge, FreeBSD has not actively supported newer FreeBSD building older FreeBSD across versions. Are you sure? I routinely build & run 12.4 and 12-stable bhyve and poudriere jail instances on -current. --
Re: NanoBSD: CURRENT unable to compile 13-STABLE : ld: error: args.o: Opaque pointers are only supported in -opaque-pointers mode (Producer: 'LLVM15.0.7' Reader: 'LLVM 14.0.5')
Mateusz Guzik wrote on
Date: Thu, 30 Mar 2023 14:56:09 UTC :
> On 3/30/23, Mateusz Guzik wrote:
> > On 3/30/23, FreeBSD User wrote:
> >> . . .
> >
>
> So I looked into it and landed
> https://cgit.FreeBSD.org/src/commit/?id=82eb549f800e08158802b74bef62e7db0939a3fe
>
> As of that commit I can both buildworld and buildkernel a stable/13
> tree while running main, without any magic to change compilers.
For reference, that patch involves:
+.if ${COMPILER_VERSION} >= 15
+CWARNFLAGS+= -Wno-error=deprecated-non-prototype
+CWARNFLAGS+= -Wno-error=array-parameter
+CWARNFLAGS+= -Wno-error=strict-prototypes
+.endif
I'm unclear here. Is the goal that a system clang 15+ toolchain
can build just the bootstrap toolchain and such that are then
used to actually build stable/13?
Otherwise I'm unclear on how compatibility with what a system
clang 14 toolchain would produce is established.
To my knowledge, FreeBSD has not actively supported newer
FreeBSD building older FreeBSD across versions. It has supported
somewhat-older building newer. I'd guess there are various
ways that having newer toolchains build compatible results
for older toolchains is messy and that FreeBSD has generally
avoided systematically dealing with such.
I'll note that even when the toolchain stays at the same LLVM
version, FreeBSD version V to V+1 gets a change in the default
target triple: even that case is a form of "cross-build" between
the older compiler and the bootstrap compiler to be used in
building V+1 (and any later V+1 compiler builds for V+1).
Has the target triple been systematically forced to be correct
for targeting the older FreeBSD?
May be just some more explanation of the context/intent will
clear my confusion(s). But for now using a system clang 15+
toolchain to produce an older FreeBSD that is based on s system
clang 14 toolchain and an older target triple seems odd to me.
===
Mark Millard
marklmi at yahoo.com
Re: NanoBSD: CURRENT unable to compile 13-STABLE : ld: error: args.o: Opaque pointers are only supported in -opaque-pointers mode (Producer: 'LLVM15.0.7' Reader: 'LLVM 14.0.5')
Am Thu, 30 Mar 2023 17:27:31 +0200 Dag-Erling Smørgrav schrieb: > FreeBSD User writes: > > I tried to put the option > > > > WITHOUT_MODULE="an" > > it's spelled WITHOUT_MODULES, cf. make.conf(5). > > DES Correct, and so I use it ... ;-) [...] # BUILD and INSTALL! # Options to put in make.conf during both build- & installworld. # See man src.conf(5) for more details on WITHOUT_ tags. CONF_WORLD=' WITHOUT_MODULES="an" WITHOUT_AMD=YES WITHOUT_APM=YES WITHOUT_ASSERT_DEBUG=YES WITHOUT_AT=YES WITHOUT_BHYVE=YES WITHOUT_BLUETOOTH=YES WITHOUT_BOOTPARAMD=YES WITHOUT_BOOTPD=YES WITHOUT_CALENDAR=YES WITHOUT_CCD=YES WITHOUT_CDDL=YES WITHOUT_CTM=YES WITHOUT_DEBUG_FILES=YES WITHOUT_DICT=YES WITHOUT_DIALOG=YES WITHOUT_EXAMPLES=YES WITHOUT_EE=YES WITHOUT_FINGER=YES WITHOUT_FLOPPY=YES WITHOUT_FREEBSD_UPDATE=YES WITHOUT_FDT=YES WITHOUT_GAMES=YES WITHOUT_GCOV=YES WITHOUT_GOOGLETEST=YES WITHOUT_HAST=YES WITHOUT_HTML=YES WITHOUT_HYPERV=YES WITHOUT_INETD=YES WITHOUT_IPFILTER=YES [...] -- O. Hartmann
Re: NanoBSD: CURRENT unable to compile 13-STABLE : ld: error: args.o: Opaque pointers are only supported in -opaque-pointers mode (Producer: 'LLVM15.0.7' Reader: 'LLVM 14.0.5')
FreeBSD User writes: > I tried to put the option > > WITHOUT_MODULE="an" it's spelled WITHOUT_MODULES, cf. make.conf(5). DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: NanoBSD: CURRENT unable to compile 13-STABLE : ld: error: args.o: Opaque pointers are only supported in -opaque-pointers mode (Producer: 'LLVM15.0.7' Reader: 'LLVM 14.0.5')
Am Thu, 30 Mar 2023 15:53:19 +0200
Mateusz Guzik schrieb:
> On 3/30/23, FreeBSD User wrote:
> > Hello folks,
> >
> > some strange misbehaviour in a NanoBSD compilation is driving me nuts.
> > Recently I posted some
> > error messages regarding
> >
> > [...]
> > 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]
> > [...]
> >
> > but being able compiling the kernel was "a lucky shot/mistake" and in the
> > vain of discussion
> > it has been revealed that my nanoBSD specific "make.conf/src.conf"
> > configurations were wrong.
> >
> > So, again:
> >
> > The builder host is a recent CURRENT (FreeBSD 14.0-CURRENT #2
> > main-n261876-f5a365e51fee: Thu
> > Mar 30 11:23:19 CEST 2023 amd64), the target is a most recent 13-STABLE (git
> > pull on a
> > daily/hourly/most recentl basis when trying to build).
> >
> > As I understand the src/buildworld config, it seems crucial to have CURRENT
> > and 13-STABLE
> > somehow separated due to their divergende in used LLVM/CLANG (CURRENT has
> > LLVM 15, 13-STABLE
> > is with LLVM 14).
> >
> > Putting
> >
> > WITHOUT_SYSTEM_COMPILER=YES
> > WITHOUT_SYSTEM_LINKER=YES
> >
> > into CONF_BUILD= AND CONF_WORLD= of NanoBSD configuration should prevent the
> > usage of
> > CURRENT's LLVM 15 and instead a cross compiling with 13-STABLE's LLVM 14
> > compiler and linker
> > should be used to buildworld.
> >
> > But this doesn't seem to happen (at least in my case), since buildworld
> > fails to build with:
> >
> > [...]
> > cc -target x86_64-unknown-freebsd13.2
> > --sysroot=/pool/home/ohartmann/Projects/router/router/apu2c4/world/obj/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp
> > -B/pool/home/ohartmann/Projects/router/router/apu2c4/world/obj/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/usr/bin
> > -O2 -pipe -fno-common -DMAINEXEC=bc -DNLSPATH=/usr/share/nls/%L/%N.cat
> > -DBUILD_TYPE=A
> > -DBC_DEFAULT_BANNER=0 -DBC_DEFAULT_PROMPT=0 -DBC_DEFAULT_SIGINT_RESET
> > -DBC_DEFAULT_TTY_MODE
> > -DBC_ENABLED -DBC_ENABLE_EDITLINE -DBC_ENABLE_EXTRA_MATH
> > -DBC_ENABLE_LIBRARY=0
> > -DBC_ENABLE_LONG_OPTIONS -DBC_ENABLE_HISTORY -DBC_ENABLE_PROMPT
> > -DBC_ENABLE_RAND
> > -DDC_DEFAULT_PROMPT=0 -DDC_DEFAULT_SIGINT_RESET -DDC_DEFAULT_TTY_MODE=0
> > -DDC_ENABLED -DNDEBUG
> > -I/pool/home/ohartmann/Projects/router/router/apu2c4/src/contrib/bc/include
> > -DBC_ENABLE_NLS=1
> > -flto -DNDEBUG -fPIE -mretpoline -ftrivial-auto-var-init=zero
> > -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang
> > -std=gnu99
> > -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Wall
> > -Wno-format-y2k -W
> > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
> > -Wpointer-arith -Wreturn-type
> > -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter
> > -Wcast-align
> > -Wchar-subscripts -Wnested-externs -Wold-style-definition -Wno-pointer-sign
> > -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body
> > -Wno-string-plus-int
> > -Wno-unused-const-variable -Wno-error=unused-but-set-variable
> > -Qunused-arguments -Wl,-zrelro
> > -pie -Wl,-zretpolineplt -o gh-bc args.o bc.o bc_lex.o bc_parse.o data.o
> > dc.o dc_lex.o
> > dc_parse.o file.o history.o lang.o lex.o main.o num.o opt.o parse.o
> > program.o rand.o read.o
> > vector.o vm.o bc_help.o dc_help.o lib.o lib2.o -ledit 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
> >
> > make[5]: stopped in
> > /pool/home/ohartmann/Projects/router/router/apu2c4/src/usr.bin/gh-bc
> > [...]
> >
> >
> > I'm now out of options here :-(
> >
>
> are you even using the dev/an driver?
No, it is commented out in the kernel config file. That error occurs when using
the CURRENT
system's compiler building the nanoBSD binaries.
>
> you should probably just remove it from the kernel (and any other
> driver of the sort)
I tried to put the option
WITHOUT_MODULE="an"
into the nanoBSD sections building world/installing world as initially
described - but without
any effect. To be honest, at this moment I'm stuck with the error reported
above in building
world preventing me proceeding to buildkernel.
>
> ultimately you should be able to stick to the compiler from main. in
> the worst case the commit to turn "function definition without a
> prototype is deprecated" from errors to warnings could be merged to
> stable/13 to facilitate the build
>
> it may be you will be able to get away with modifying CFLAGS like so:
> CFLAGS+=-Wno-deprecated-non-prototype
Well, I live my freeBSD life under the impression using
WITHOUT_SYSTEM_{COMPILER|LINKER}
gives
Re: NanoBSD: CURRENT unable to compile 13-STABLE : ld: error: args.o: Opaque pointers are only supported in -opaque-pointers mode (Producer: 'LLVM15.0.7' Reader: 'LLVM 14.0.5')
Am Thu, 30 Mar 2023 16:56:09 +0200 Mateusz Guzik schrieb: > On 3/30/23, Mateusz Guzik wrote: > > On 3/30/23, FreeBSD User wrote: > >> Hello folks, > >> > >> some strange misbehaviour in a NanoBSD compilation is driving me nuts. > >> Recently I posted some > >> error messages regarding > >> > >> [...] > >> 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] > >> [...] > >> > >> but being able compiling the kernel was "a lucky shot/mistake" and in the > >> vain of discussion > >> it has been revealed that my nanoBSD specific "make.conf/src.conf" > >> configurations were wrong. > >> > >> So, again: > >> > >> The builder host is a recent CURRENT (FreeBSD 14.0-CURRENT #2 > >> main-n261876-f5a365e51fee: Thu > >> Mar 30 11:23:19 CEST 2023 amd64), the target is a most recent 13-STABLE > >> (git > >> pull on a > >> daily/hourly/most recentl basis when trying to build). > >> > >> As I understand the src/buildworld config, it seems crucial to have > >> CURRENT > >> and 13-STABLE > >> somehow separated due to their divergende in used LLVM/CLANG (CURRENT has > >> LLVM 15, 13-STABLE > >> is with LLVM 14). > >> > >> Putting > >> > >> WITHOUT_SYSTEM_COMPILER=YES > >> WITHOUT_SYSTEM_LINKER=YES > >> > >> into CONF_BUILD= AND CONF_WORLD= of NanoBSD configuration should prevent > >> the > >> usage of > >> CURRENT's LLVM 15 and instead a cross compiling with 13-STABLE's LLVM 14 > >> compiler and linker > >> should be used to buildworld. > >> > >> But this doesn't seem to happen (at least in my case), since buildworld > >> fails to build with: > >> > >> [...] > >> cc -target x86_64-unknown-freebsd13.2 > >> --sysroot=/pool/home/ohartmann/Projects/router/router/apu2c4/world/obj/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp > >> -B/pool/home/ohartmann/Projects/router/router/apu2c4/world/obj/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/usr/bin > >> -O2 -pipe -fno-common -DMAINEXEC=bc -DNLSPATH=/usr/share/nls/%L/%N.cat > >> -DBUILD_TYPE=A > >> -DBC_DEFAULT_BANNER=0 -DBC_DEFAULT_PROMPT=0 -DBC_DEFAULT_SIGINT_RESET > >> -DBC_DEFAULT_TTY_MODE > >> -DBC_ENABLED -DBC_ENABLE_EDITLINE -DBC_ENABLE_EXTRA_MATH > >> -DBC_ENABLE_LIBRARY=0 > >> -DBC_ENABLE_LONG_OPTIONS -DBC_ENABLE_HISTORY -DBC_ENABLE_PROMPT > >> -DBC_ENABLE_RAND > >> -DDC_DEFAULT_PROMPT=0 -DDC_DEFAULT_SIGINT_RESET -DDC_DEFAULT_TTY_MODE=0 > >> -DDC_ENABLED -DNDEBUG > >> -I/pool/home/ohartmann/Projects/router/router/apu2c4/src/contrib/bc/include > >> -DBC_ENABLE_NLS=1 > >> -flto -DNDEBUG -fPIE -mretpoline -ftrivial-auto-var-init=zero > >> -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang > >> -std=gnu99 > >> -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Wall > >> -Wno-format-y2k -W > >> -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes > >> -Wpointer-arith -Wreturn-type > >> -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter > >> -Wcast-align > >> -Wchar-subscripts -Wnested-externs -Wold-style-definition > >> -Wno-pointer-sign > >> -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body > >> -Wno-string-plus-int > >> -Wno-unused-const-variable -Wno-error=unused-but-set-variable > >> -Qunused-arguments -Wl,-zrelro > >> -pie -Wl,-zretpolineplt -o gh-bc args.o bc.o bc_lex.o bc_parse.o data.o > >> dc.o dc_lex.o > >> dc_parse.o file.o history.o lang.o lex.o main.o num.o opt.o parse.o > >> program.o rand.o read.o > >> vector.o vm.o bc_help.o dc_help.o lib.o lib2.o -ledit 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 > >> > >> make[5]: stopped in > >> /pool/home/ohartmann/Projects/router/router/apu2c4/src/usr.bin/gh-bc > >> [...] > >> > >> > >> I'm now out of options here :-( > >> > > > > are you even using the dev/an driver? > > > > you should probably just remove it from the kernel (and any other > > driver of the sort) > > > > ultimately you should be able to stick to the compiler from main. in > > the worst case the commit to turn "function definition without a > > prototype is deprecated" from errors to warnings could be merged to > > stable/13 to facilitate the build > > > > it may be you will be able to get away with modifying CFLAGS like so: > > CFLAGS+=-Wno-deprecated-non-prototype > > > > in src.conf and/or make.conf > > > > So I looked into it and landed > https://cgit.FreeBSD.org/src/commit/?id=82eb549f800e08158802b74bef62e7db0939a3fe > > As of that commit I can both buildworld and buildkernel a stable/13 > tree while running main, without any magic to change compilers. > Running poudriere on another most
Re: NanoBSD: CURRENT unable to compile 13-STABLE : ld: error: args.o: Opaque pointers are only supported in -opaque-pointers mode (Producer: 'LLVM15.0.7' Reader: 'LLVM 14.0.5')
On 3/30/23, Mateusz Guzik wrote: > On 3/30/23, FreeBSD User wrote: >> Hello folks, >> >> some strange misbehaviour in a NanoBSD compilation is driving me nuts. >> Recently I posted some >> error messages regarding >> >> [...] >> 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] >> [...] >> >> but being able compiling the kernel was "a lucky shot/mistake" and in the >> vain of discussion >> it has been revealed that my nanoBSD specific "make.conf/src.conf" >> configurations were wrong. >> >> So, again: >> >> The builder host is a recent CURRENT (FreeBSD 14.0-CURRENT #2 >> main-n261876-f5a365e51fee: Thu >> Mar 30 11:23:19 CEST 2023 amd64), the target is a most recent 13-STABLE >> (git >> pull on a >> daily/hourly/most recentl basis when trying to build). >> >> As I understand the src/buildworld config, it seems crucial to have >> CURRENT >> and 13-STABLE >> somehow separated due to their divergende in used LLVM/CLANG (CURRENT has >> LLVM 15, 13-STABLE >> is with LLVM 14). >> >> Putting >> >> WITHOUT_SYSTEM_COMPILER=YES >> WITHOUT_SYSTEM_LINKER=YES >> >> into CONF_BUILD= AND CONF_WORLD= of NanoBSD configuration should prevent >> the >> usage of >> CURRENT's LLVM 15 and instead a cross compiling with 13-STABLE's LLVM 14 >> compiler and linker >> should be used to buildworld. >> >> But this doesn't seem to happen (at least in my case), since buildworld >> fails to build with: >> >> [...] >> cc -target x86_64-unknown-freebsd13.2 >> --sysroot=/pool/home/ohartmann/Projects/router/router/apu2c4/world/obj/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp >> -B/pool/home/ohartmann/Projects/router/router/apu2c4/world/obj/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/usr/bin >> -O2 -pipe -fno-common -DMAINEXEC=bc -DNLSPATH=/usr/share/nls/%L/%N.cat >> -DBUILD_TYPE=A >> -DBC_DEFAULT_BANNER=0 -DBC_DEFAULT_PROMPT=0 -DBC_DEFAULT_SIGINT_RESET >> -DBC_DEFAULT_TTY_MODE >> -DBC_ENABLED -DBC_ENABLE_EDITLINE -DBC_ENABLE_EXTRA_MATH >> -DBC_ENABLE_LIBRARY=0 >> -DBC_ENABLE_LONG_OPTIONS -DBC_ENABLE_HISTORY -DBC_ENABLE_PROMPT >> -DBC_ENABLE_RAND >> -DDC_DEFAULT_PROMPT=0 -DDC_DEFAULT_SIGINT_RESET -DDC_DEFAULT_TTY_MODE=0 >> -DDC_ENABLED -DNDEBUG >> -I/pool/home/ohartmann/Projects/router/router/apu2c4/src/contrib/bc/include >> -DBC_ENABLE_NLS=1 >> -flto -DNDEBUG -fPIE -mretpoline -ftrivial-auto-var-init=zero >> -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang >> -std=gnu99 >> -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Wall >> -Wno-format-y2k -W >> -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes >> -Wpointer-arith -Wreturn-type >> -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter >> -Wcast-align >> -Wchar-subscripts -Wnested-externs -Wold-style-definition >> -Wno-pointer-sign >> -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body >> -Wno-string-plus-int >> -Wno-unused-const-variable -Wno-error=unused-but-set-variable >> -Qunused-arguments -Wl,-zrelro >> -pie -Wl,-zretpolineplt -o gh-bc args.o bc.o bc_lex.o bc_parse.o data.o >> dc.o dc_lex.o >> dc_parse.o file.o history.o lang.o lex.o main.o num.o opt.o parse.o >> program.o rand.o read.o >> vector.o vm.o bc_help.o dc_help.o lib.o lib2.o -ledit 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 >> >> make[5]: stopped in >> /pool/home/ohartmann/Projects/router/router/apu2c4/src/usr.bin/gh-bc >> [...] >> >> >> I'm now out of options here :-( >> > > are you even using the dev/an driver? > > you should probably just remove it from the kernel (and any other > driver of the sort) > > ultimately you should be able to stick to the compiler from main. in > the worst case the commit to turn "function definition without a > prototype is deprecated" from errors to warnings could be merged to > stable/13 to facilitate the build > > it may be you will be able to get away with modifying CFLAGS like so: > CFLAGS+=-Wno-deprecated-non-prototype > > in src.conf and/or make.conf > So I looked into it and landed https://cgit.FreeBSD.org/src/commit/?id=82eb549f800e08158802b74bef62e7db0939a3fe As of that commit I can both buildworld and buildkernel a stable/13 tree while running main, without any magic to change compilers. -- Mateusz Guzik
Re: NanoBSD: CURRENT unable to compile 13-STABLE : ld: error: args.o: Opaque pointers are only supported in -opaque-pointers mode (Producer: 'LLVM15.0.7' Reader: 'LLVM 14.0.5')
On 3/30/23, FreeBSD User wrote: > Hello folks, > > some strange misbehaviour in a NanoBSD compilation is driving me nuts. > Recently I posted some > error messages regarding > > [...] > 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] > [...] > > but being able compiling the kernel was "a lucky shot/mistake" and in the > vain of discussion > it has been revealed that my nanoBSD specific "make.conf/src.conf" > configurations were wrong. > > So, again: > > The builder host is a recent CURRENT (FreeBSD 14.0-CURRENT #2 > main-n261876-f5a365e51fee: Thu > Mar 30 11:23:19 CEST 2023 amd64), the target is a most recent 13-STABLE (git > pull on a > daily/hourly/most recentl basis when trying to build). > > As I understand the src/buildworld config, it seems crucial to have CURRENT > and 13-STABLE > somehow separated due to their divergende in used LLVM/CLANG (CURRENT has > LLVM 15, 13-STABLE > is with LLVM 14). > > Putting > > WITHOUT_SYSTEM_COMPILER=YES > WITHOUT_SYSTEM_LINKER=YES > > into CONF_BUILD= AND CONF_WORLD= of NanoBSD configuration should prevent the > usage of > CURRENT's LLVM 15 and instead a cross compiling with 13-STABLE's LLVM 14 > compiler and linker > should be used to buildworld. > > But this doesn't seem to happen (at least in my case), since buildworld > fails to build with: > > [...] > cc -target x86_64-unknown-freebsd13.2 > --sysroot=/pool/home/ohartmann/Projects/router/router/apu2c4/world/obj/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp > -B/pool/home/ohartmann/Projects/router/router/apu2c4/world/obj/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/usr/bin > -O2 -pipe -fno-common -DMAINEXEC=bc -DNLSPATH=/usr/share/nls/%L/%N.cat > -DBUILD_TYPE=A > -DBC_DEFAULT_BANNER=0 -DBC_DEFAULT_PROMPT=0 -DBC_DEFAULT_SIGINT_RESET > -DBC_DEFAULT_TTY_MODE > -DBC_ENABLED -DBC_ENABLE_EDITLINE -DBC_ENABLE_EXTRA_MATH > -DBC_ENABLE_LIBRARY=0 > -DBC_ENABLE_LONG_OPTIONS -DBC_ENABLE_HISTORY -DBC_ENABLE_PROMPT > -DBC_ENABLE_RAND > -DDC_DEFAULT_PROMPT=0 -DDC_DEFAULT_SIGINT_RESET -DDC_DEFAULT_TTY_MODE=0 > -DDC_ENABLED -DNDEBUG > -I/pool/home/ohartmann/Projects/router/router/apu2c4/src/contrib/bc/include > -DBC_ENABLE_NLS=1 > -flto -DNDEBUG -fPIE -mretpoline -ftrivial-auto-var-init=zero > -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang > -std=gnu99 > -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Wall > -Wno-format-y2k -W > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wreturn-type > -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter > -Wcast-align > -Wchar-subscripts -Wnested-externs -Wold-style-definition -Wno-pointer-sign > -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body > -Wno-string-plus-int > -Wno-unused-const-variable -Wno-error=unused-but-set-variable > -Qunused-arguments -Wl,-zrelro > -pie -Wl,-zretpolineplt -o gh-bc args.o bc.o bc_lex.o bc_parse.o data.o > dc.o dc_lex.o > dc_parse.o file.o history.o lang.o lex.o main.o num.o opt.o parse.o > program.o rand.o read.o > vector.o vm.o bc_help.o dc_help.o lib.o lib2.o -ledit 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 > > make[5]: stopped in > /pool/home/ohartmann/Projects/router/router/apu2c4/src/usr.bin/gh-bc > [...] > > > I'm now out of options here :-( > are you even using the dev/an driver? you should probably just remove it from the kernel (and any other driver of the sort) ultimately you should be able to stick to the compiler from main. in the worst case the commit to turn "function definition without a prototype is deprecated" from errors to warnings could be merged to stable/13 to facilitate the build it may be you will be able to get away with modifying CFLAGS like so: CFLAGS+=-Wno-deprecated-non-prototype in src.conf and/or make.conf -- Mateusz Guzik
NanoBSD: CURRENT unable to compile 13-STABLE : ld: error: args.o: Opaque pointers are only supported in -opaque-pointers mode (Producer: 'LLVM15.0.7' Reader: 'LLVM 14.0.5')
Hello folks, some strange misbehaviour in a NanoBSD compilation is driving me nuts. Recently I posted some error messages regarding [...] 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] [...] but being able compiling the kernel was "a lucky shot/mistake" and in the vain of discussion it has been revealed that my nanoBSD specific "make.conf/src.conf" configurations were wrong. So, again: The builder host is a recent CURRENT (FreeBSD 14.0-CURRENT #2 main-n261876-f5a365e51fee: Thu Mar 30 11:23:19 CEST 2023 amd64), the target is a most recent 13-STABLE (git pull on a daily/hourly/most recentl basis when trying to build). As I understand the src/buildworld config, it seems crucial to have CURRENT and 13-STABLE somehow separated due to their divergende in used LLVM/CLANG (CURRENT has LLVM 15, 13-STABLE is with LLVM 14). Putting WITHOUT_SYSTEM_COMPILER=YES WITHOUT_SYSTEM_LINKER=YES into CONF_BUILD= AND CONF_WORLD= of NanoBSD configuration should prevent the usage of CURRENT's LLVM 15 and instead a cross compiling with 13-STABLE's LLVM 14 compiler and linker should be used to buildworld. But this doesn't seem to happen (at least in my case), since buildworld fails to build with: [...] cc -target x86_64-unknown-freebsd13.2 --sysroot=/pool/home/ohartmann/Projects/router/router/apu2c4/world/obj/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp -B/pool/home/ohartmann/Projects/router/router/apu2c4/world/obj/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/usr/bin -O2 -pipe -fno-common -DMAINEXEC=bc -DNLSPATH=/usr/share/nls/%L/%N.cat -DBUILD_TYPE=A -DBC_DEFAULT_BANNER=0 -DBC_DEFAULT_PROMPT=0 -DBC_DEFAULT_SIGINT_RESET -DBC_DEFAULT_TTY_MODE -DBC_ENABLED -DBC_ENABLE_EDITLINE -DBC_ENABLE_EXTRA_MATH -DBC_ENABLE_LIBRARY=0 -DBC_ENABLE_LONG_OPTIONS -DBC_ENABLE_HISTORY -DBC_ENABLE_PROMPT -DBC_ENABLE_RAND -DDC_DEFAULT_PROMPT=0 -DDC_DEFAULT_SIGINT_RESET -DDC_DEFAULT_TTY_MODE=0 -DDC_ENABLED -DNDEBUG -I/pool/home/ohartmann/Projects/router/router/apu2c4/src/contrib/bc/include -DBC_ENABLE_NLS=1 -flto -DNDEBUG -fPIE -mretpoline -ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Wnested-externs -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-variable -Qunused-arguments -Wl,-zrelro -pie -Wl,-zretpolineplt -o gh-bc args.o bc.o bc_lex.o bc_parse.o data.o dc.o dc_lex.o dc_parse.o file.o history.o lang.o lex.o main.o num.o opt.o parse.o program.o rand.o read.o vector.o vm.o bc_help.o dc_help.o lib.o lib2.o -ledit 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 make[5]: stopped in /pool/home/ohartmann/Projects/router/router/apu2c4/src/usr.bin/gh-bc [...] I'm now out of options here :-( Thanks in advance, Oliver -- O. Hartmann
