> -----Original Message-----
> From: Richard Purdie <richard.pur...@linuxfoundation.org>
> Sent: den 13 juni 2024 23:59
> To: Peter Kjellerstedt <peter.kjellerst...@axis.com>;
> changqing...@windriver.com; openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] expect-native: fix build with gcc-14
> 
> On Thu, 2024-06-13 at 21:55 +0000, Peter Kjellerstedt wrote:
> > > -----Original Message-----
> > > From:
> > > openembedded-core@lists.openembedded.org <openembedded-
> c...@lists.openembedded.org
> > > > On Behalf Of Richard Purdie
> > > Sent: den 13 juni 2024 10:40
> > > To: changqing...@windriver.com;
> > > openembedded-core@lists.openembedded.org
> > > Subject: Re: [OE-core] [PATCH] expect-native: fix build with gcc-14
> > >
> > > On Thu, 2024-06-13 at 14:18 +0800, Changqing Li via
> > > lists.openembedded.org wrote:
> > > > From: Changqing Li <changqing...@windriver.com>
> > > >
> > > > * do_configure failed with gcc-14:
> > > > error in build/config.log:
> > > > conftest.c:56:3: error: return type defaults to 'int' [-
> > > > Wimplicit-int]
> > > > conftest.c:59:5: error: implicit declaration of function 'exit'
> > > > [-Wimplicit-function-declaration]
> > > >
> > > > * this recipe set "BBCLASSEXTEND = "native nativesdk", causes
> > > > "CFLAGS +="
> > > > setting not take effect, use append instead.
> > > > snip of bitbake expect-native -e:
> > > >    set /layers/oe-core/meta/conf/documentation.conf:110
> > > >      [doc] "Flags passed to the C compiler for the target system.
> > > > This variable evaluates to the same as TARGET_CFLAGS."
> > > >    append /layers/oe-core/meta/recipes-
> > > > devtools/expect/expect_5.45.4.bb:87
> > > >      "-Wno-error=incompatible-pointer-types"
> > > >    set /layers/oe-core/meta/classes-recipe/native.bbclass:44
> > > >      "${BUILD_CFLAGS}"
> > > >    override[pn-gtk4]::append[toolchain-clang] /layers/meta-
> > > > clang/conf/nonclangable.conf:336
> > > >      " -Wno-error=int-conversion"
> > > >    override[pn-pidgin-sipe]::append[toolchain-clang]
> > > > /layers/meta-clang/conf/nonclangable.conf:340
> > > >      " -Wno-error=cast-function-type-strict"
> > > >  pre-expansion value:
> > > >    "${BUILD_CFLAGS}"
> > > > export CFLAGS="-isystem/build/tmp-glibc/work/x86_64-linux/expect-
> > > > native/5.45.4/recipe-sysroot-native/usr/include -O2 -pipe"
> > > >
> > > > Signed-off-by: Changqing Li <changqing...@windriver.com>
> > > > ---
> > > >  meta/recipes-devtools/expect/expect_5.45.4.bb | 5 ++++-
> > > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/meta/recipes-devtools/expect/expect_5.45.4.bb
> > > > b/meta/recipes-devtools/expect/expect_5.45.4.bb
> > > > index 18904ebc10..5e7b352196 100644
> > > > --- a/meta/recipes-devtools/expect/expect_5.45.4.bb
> > > > +++ b/meta/recipes-devtools/expect/expect_5.45.4.bb
> > > > @@ -84,4 +84,7 @@ BBCLASSEXTEND = "native nativesdk"
> > > >
> > > >  # http://errors.yoctoproject.org/Errors/Details/766950/
> > > >  # expect5.45.4/exp_chan.c:62:5: error: initialization of 'struct
> > > > Tcl_ChannelTypeVersion_ *' from incompatible pointer type 'int
> > > > (*)(void *, int)' [-Wincompatible-pointer-types]
> > > > -CFLAGS += "-Wno-error=incompatible-pointer-types"
> > > > +CFLAGS:append = " -Wno-error=incompatible-pointer-types"
> > > > +
> > > > +# Fix expect-native configure tests are failing with gcc-14
> > > > +CFLAGS:append:class-native = " -Wno-error=implicit-int -Wno-
> > > > error=implicit-function-declaration"
> > > >
> > >
> > > You have a valid problem here however I really don't like the "arms
> > > race" of making everything an append as the base definitions are
> > > problematic. It would be this recipe today but a quick search shows
> > > many other recipes which will have similar problems.
> > >
> > > I think I'd prefer to see if we can drop the assignments in
> > > native/nativesdk bbclass and improve things that way even if it is
> > > a
> > > bit more invasive.
> > >
> > > I'm testing a patch on master-next to test this and see how bad the
> > > fallout is.
> > >
> > > Cheers,
> > >
> > > Richard
> >
> > Isn't the correct thing to add to CFLAGS (really TARGET_CFLAGS)
> > and/or BUILD_CFLAGS as appropriate? If the same options are needed
> > for both target and native, then you can use an intermediary
> > variable. E.g., for  the above case you would get something like:
> >
> > COMMON_CFLAGS = "-Wno-error=incompatible-pointer-types"
> > CFLAGS += "${COMMON_CFLAGS}"
> > BUILD_CFLAGS += " \
> >     ${COMMON_CFLAGS} \
> >     -Wno-error=implicit-int \
> >     -Wno-error=implicit-function-declaration \
> > "
> 
> 
> We could require that but I don't think it is what people expect, or
> how things were meant to work. I've sent the patch I was thinking off
> now as it seems to work ok in testing so far. In most cases recipe
> writers don't need/want separate flags for native/nativesdk/target.
> 
> Cheers,
> 
> Richard

Interesting. Being able to add to CFLAGS and have the options apply 
for all cases seems a lot more intuitive than how it was.

There is (at least) one corner case though. If you do 
TARGET_CFLAGS:append = " ...", then that will actually apply to the 
native and nativesdk builds too now.

To verify the above, I added the following to the dos2unix recipe:

CFLAGS += "-DADD_BOTH"
TARGET_CFLAGS += "-DADD_TARGET"
BUILD_CFLAGS += " -DADD_NATIVE"

CFLAGS:append = " -DAPPEND_BOTH"
TARGET_CFLAGS:append = " -DAPPEND_TARGET"
BUILD_CFLAGS:append = " -DAPPEND_NATIVE"

and then ran the following two commands:

$ bitbake-getvar -q --value -r dos2unix CFLAGS
 -O2 -pipe -g ... -DADD_TARGET -DAPPEND_TARGET -DADD_BOTH -DAPPEND_BOTH
$ bitbake-getvar -q --value -r dos2unix-native CFLAGS
 ... -O2 -pipe  -DADD_NATIVE -DAPPEND_NATIVE -DAPPEND_TARGET -DADD_BOTH 
-DAPPEND_BOTH

As you can see, the -DAPPEND_TARGET is present in both cases. :(

Now, appending to TARGET_CFLAGS like that is probably not very 
common, but there are two examples in OE-Core 
(TARGET_CFLAGS:append:qemuriscv64 = " ...") and two more in 
meta-openembedded. Neither of those four recipes use 
BBCLASSEXTEND though so this change wouldn't be a problem for 
either of them in practice. And a simple workaround, if you know 
about this, would be to use CFLAGS:append:class-target instead.

//Peter

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#200643): 
https://lists.openembedded.org/g/openembedded-core/message/200643
Mute This Topic: https://lists.openembedded.org/mt/106647106/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to