| Message ID | CAPWx8vsoJUt8YMJG1aUqFRK1=yizNbgjVjGL1Q1+9ygjJGnZLA@mail.gmail.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | host-m4 build on Fedora 42 fails | expand |
Hi Joseph, Thanks for reporting the issue. On 18/04/2025 16:14, Joseph Zikusooka wrote: > Recently upgraded to Fedora 42 and since then I am unable to compile > buildroot. Make fails at the host-m4 package. > I looked up several sources and found this: > https://lists.gnu.org/archive/html/m4-discuss/2025-02/msg00000.html > > The work around on Fedora 42 was to build m4 with the environment > flags as follows: > CFLAGS='-std=gnu17' ./configure && make > > I tried to patch m4.mk as follows, but the build is still failing. Any > ideas? > > --- a/m4.mk 2025-04-18 17:02:01.174923317 +0300 > +++ b/m4.mk 2025-04-18 17:03:29.285694673 +0300 > @@ -10,4 +10,7 @@ > M4_LICENSE = GPL-3.0+ > M4_LICENSE_FILES = COPYING > > +M4_CONF_ENV = CFLAGS="-std=gnu17" > +M4_MAKE_ENV = CFLAGS="-std=gnu17" > + To workaround this gcc15 issue with the current m4 version 1.4.19, you should probably pass the CFLAGS as: HOST_M4_CONF_ENV = CFLAGS="$(HOST_CFLAGS) -std=gnu17" Also, there is an upcoming m4 release which will fix this gcc 15 issue. See: https://git.savannah.gnu.org/cgit/m4.git/commit/?h=branch-1.4&id=a22c9802dd7e724eaefb21dc21d84ac2d3a49c89 More specifically: " ** Update to comply with newer C standards, and inherit portability improvements from gnulib. " If this new m4 release is not published in the coming days/weeks please submit an updated version of this patch to fix this issue. Please also add a comment that this CFLAGS modification is needed for m4-1.4.19 and host-gcc15 and should be removed in the next bump to 1.4.20. Best regards, Julien.
Hi Julien, Thanks for the info and the workaround tip! I updated my patch to use CFLAGS="$(HOST_CFLAGS) -std=gnu17" like you suggested, but the build still fails with GCC 15 and m4 1.4.19 - same errors as before. Strangely, if I build m4 outside the buildroot environment with those flags, it works fine. Any idea what else could be causing the workaround to fail in buildroot? Are there other flags or tweaks I could try in m4.mk until the new m4 release is out? Regards, Joseph Zikusooka (ZIK) On Sat, Apr 19, 2025, 3:29 PM Julien Olivain <ju.o@free.fr> wrote: > Hi Joseph, > > Thanks for reporting the issue. > > On 18/04/2025 16:14, Joseph Zikusooka wrote: > > Recently upgraded to Fedora 42 and since then I am unable to compile > > buildroot. Make fails at the host-m4 package. > > I looked up several sources and found this: > > https://lists.gnu.org/archive/html/m4-discuss/2025-02/msg00000.html > > > > The work around on Fedora 42 was to build m4 with the environment > > flags as follows: > > CFLAGS='-std=gnu17' ./configure && make > > > > I tried to patch m4.mk as follows, but the build is still failing. Any > > ideas? > > > > --- a/m4.mk 2025-04-18 17:02:01.174923317 +0300 > > +++ b/m4.mk 2025-04-18 17:03:29.285694673 +0300 > > @@ -10,4 +10,7 @@ > > M4_LICENSE = GPL-3.0+ > > M4_LICENSE_FILES = COPYING > > > > +M4_CONF_ENV = CFLAGS="-std=gnu17" > > +M4_MAKE_ENV = CFLAGS="-std=gnu17" > > + > > To workaround this gcc15 issue with the current m4 > version 1.4.19, you should probably pass the CFLAGS as: > > HOST_M4_CONF_ENV = CFLAGS="$(HOST_CFLAGS) -std=gnu17" > > Also, there is an upcoming m4 release which will fix > this gcc 15 issue. See: > > https://git.savannah.gnu.org/cgit/m4.git/commit/?h=branch-1.4&id=a22c9802dd7e724eaefb21dc21d84ac2d3a49c89 > > More specifically: > " > ** Update to comply with newer C standards, and inherit portability > improvements from gnulib. > " > > If this new m4 release is not published in the coming days/weeks > please submit an updated version of this patch to fix this issue. > Please also add a comment that this CFLAGS modification is needed > for m4-1.4.19 and host-gcc15 and should be removed in the next > bump to 1.4.20. > > Best regards, > > Julien. >
Hi Joseph, On 19/04/2025 18:56, Joseph Zikusooka wrote: > Hi Julien, > > Thanks for the info and the workaround tip! > > I updated my patch to use CFLAGS="$(HOST_CFLAGS) -std=gnu17" like you > suggested, but the build still fails with GCC 15 and m4 1.4.19 - same > errors as before. Strangely, if I build m4 outside the buildroot > environment with those flags, it works fine. > > Any idea what else could be causing the workaround to fail in > buildroot? Are there other flags or tweaks I could try in m4.mk [1] > until the new m4 release is out? I just tried adding the line I suggested in package/m4/m4.mk: HOST_M4_CONF_ENV = CFLAGS="$(HOST_CFLAGS) -std=gnu17" On a Fedora 42 host system (updated as of now), it solves the host-m4 build issue. You need to restart from a clean build, though. I tested with the commands: make qemu_aarch64_virt_defconfig make clean make Could you check on your side, please? Best regards, Julien.
Hi Julien, Thanks, that solved the problem! I needed to run "make distclean" before building with the updated m4.mk file. While we wait for a new m4 release from upstream, I’m sharing the patch that worked for me in case anyone else encounters this issue. --- a/package/m4/m4.mk 2025-04-03 13:59:27.224254338 +0300 +++ b/package/m4/m4.mk 2025-04-21 21:04:22.107546262 +0300 @@ -10,4 +10,8 @@ M4_LICENSE = GPL-3.0+ M4_LICENSE_FILES = COPYING +HOST_M4_CONF_ENV = CFLAGS="$(HOST_CFLAGS) -std=gnu17" + +HOST_M4_CONF_ENV = CFLAGS="$(HOST_CFLAGS) -std=gnu17" + $(eval $(host-autotools-package)) On Mon, Apr 21, 2025 at 5:00 PM Julien Olivain <ju.o@free.fr> wrote: > > Hi Joseph, > > On 19/04/2025 18:56, Joseph Zikusooka wrote: > > Hi Julien, > > > > Thanks for the info and the workaround tip! > > > > I updated my patch to use CFLAGS="$(HOST_CFLAGS) -std=gnu17" like you > > suggested, but the build still fails with GCC 15 and m4 1.4.19 - same > > errors as before. Strangely, if I build m4 outside the buildroot > > environment with those flags, it works fine. > > > > Any idea what else could be causing the workaround to fail in > > buildroot? Are there other flags or tweaks I could try in m4.mk [1] > > until the new m4 release is out? > > I just tried adding the line I suggested in package/m4/m4.mk: > HOST_M4_CONF_ENV = CFLAGS="$(HOST_CFLAGS) -std=gnu17" > > On a Fedora 42 host system (updated as of now), it solves the > host-m4 build issue. You need to restart from a clean build, > though. > > I tested with the commands: > > make qemu_aarch64_virt_defconfig > make clean > make > > Could you check on your side, please? > > Best regards, > > Julien.
I think I rushed the previous patch - here’s the corrected version. --- a/package/m4/m4.mk 2025-04-03 13:59:27.224254338 +0300 +++ b/package/m4/m4.mk 2025-04-21 21:41:45.589717302 +0300 @@ -10,4 +10,6 @@ M4_LICENSE = GPL-3.0+ M4_LICENSE_FILES = COPYING +HOST_M4_CONF_ENV = CFLAGS="$(HOST_CFLAGS) -std=gnu17" + $(eval $(host-autotools-package)) On Mon, Apr 21, 2025 at 9:21 PM Joseph Zikusooka <josephzik@gmail.com> wrote: > > Hi Julien, > > Thanks, that solved the problem! I needed to run "make distclean" > before building with the updated m4.mk file. While we wait for a new > m4 release from upstream, I’m sharing the patch that worked for me in > case anyone else encounters this issue. > > --- a/package/m4/m4.mk 2025-04-03 13:59:27.224254338 +0300 > +++ b/package/m4/m4.mk 2025-04-21 21:04:22.107546262 +0300 > @@ -10,4 +10,8 @@ > M4_LICENSE = GPL-3.0+ > M4_LICENSE_FILES = COPYING > > +HOST_M4_CONF_ENV = CFLAGS="$(HOST_CFLAGS) -std=gnu17" > + > +HOST_M4_CONF_ENV = CFLAGS="$(HOST_CFLAGS) -std=gnu17" > + > $(eval $(host-autotools-package)) > > On Mon, Apr 21, 2025 at 5:00 PM Julien Olivain <ju.o@free.fr> wrote: > > > > Hi Joseph, > > > > On 19/04/2025 18:56, Joseph Zikusooka wrote: > > > Hi Julien, > > > > > > Thanks for the info and the workaround tip! > > > > > > I updated my patch to use CFLAGS="$(HOST_CFLAGS) -std=gnu17" like you > > > suggested, but the build still fails with GCC 15 and m4 1.4.19 - same > > > errors as before. Strangely, if I build m4 outside the buildroot > > > environment with those flags, it works fine. > > > > > > Any idea what else could be causing the workaround to fail in > > > buildroot? Are there other flags or tweaks I could try in m4.mk [1] > > > until the new m4 release is out? > > > > I just tried adding the line I suggested in package/m4/m4.mk: > > HOST_M4_CONF_ENV = CFLAGS="$(HOST_CFLAGS) -std=gnu17" > > > > On a Fedora 42 host system (updated as of now), it solves the > > host-m4 build issue. You need to restart from a clean build, > > though. > > > > I tested with the commands: > > > > make qemu_aarch64_virt_defconfig > > make clean > > make > > > > Could you check on your side, please? > > > > Best regards, > > > > Julien. > > > > -- > Joseph Zikusooka
Hi Joseph, On 21/04/2025 21:02, Joseph Zikusooka wrote: > I think I rushed the previous patch - here’s the corrected version. > > > --- a/package/m4/m4.mk 2025-04-03 13:59:27.224254338 +0300 > +++ b/package/m4/m4.mk 2025-04-21 21:41:45.589717302 +0300 > @@ -10,4 +10,6 @@ > M4_LICENSE = GPL-3.0+ > M4_LICENSE_FILES = COPYING > > +HOST_M4_CONF_ENV = CFLAGS="$(HOST_CFLAGS) -std=gnu17" > + > $(eval $(host-autotools-package)) > > On Mon, Apr 21, 2025 at 9:21 PM Joseph Zikusooka <josephzik@gmail.com> > wrote: >> >> Hi Julien, >> >> Thanks, that solved the problem! I needed to run "make distclean" >> before building with the updated m4.mk file. While we wait for a new >> m4 release from upstream, I’m sharing the patch that worked for me in >> case anyone else encounters this issue. Thank you for the confirmation. Could you send a new updated patch with this fix, please? Best regards, Julien.
--- a/m4.mk 2025-04-18 17:02:01.174923317 +0300 +++ b/m4.mk 2025-04-18 17:03:29.285694673 +0300 @@ -10,4 +10,7 @@ M4_LICENSE = GPL-3.0+ M4_LICENSE_FILES = COPYING +M4_CONF_ENV = CFLAGS="-std=gnu17" +M4_MAKE_ENV = CFLAGS="-std=gnu17" + $(eval $(host-autotools-package))