[PATCH v2] bfd/elf32-or1k: fix building with gcc version < 5

Stafford Horne shorne@gmail.com
Thu Jun 10 19:23:55 GMT 2021


On Thu, Jun 10, 2021 at 04:48:46PM +0200, Giulio Benetti wrote:
> Hello Alan, All,
> 
> On 6/10/21 3:06 PM, Alan Modra wrote:
> > On Thu, Jun 10, 2021 at 11:07:13AM +0200, Giulio Benetti wrote:
> > > Hello Alan, All,
> > > 
> > > On 6/10/21 3:19 AM, Alan Modra wrote:
> > > > On Wed, Jun 09, 2021 at 11:52:33PM +0200, Giulio Benetti wrote:
> > > > > Gcc version >= 5 has standard C mode not set to -std=gnu11, so if we use
> > > > > an old compiler(i.e. gcc 4.9) build fails on:
> > > > > ```
> > > > > elf32-or1k.c:2251:3: error: 'for' loop initial declarations are only allowed in
> > > > > C99 or C11 mode
> > > > >       for (size_t i = 0; i < insn_count; i++)
> > > > >       ^
> > > > > ```
> > > > 
> > > > Did you find this problem on current mainline binutils?  The configure
> > > > machinery is supposed to supply the appropriate -std=c99 or -std=gnu99
> > > > when using older compilers.  That happens for me when I build with
> > > > gcc-4.9.  I don't think any patch is needed for mainline.
> > > > 
> > > 
> > > On Buildroot they don't pass -std=c99/g99 and this is the result:
> > > https://gitlab.com/bootlin/toolchains-builder/-/jobs/1325646298
> > 
> > That appears to be building binutils 2.35.2
> > 
> > > This patch seems to follow all the rest code style of binutils
> > 
> > True, we've only just switched over to requiring C99.
> 
> Ok so...
> 
> > > since no
> > > other part of it fails and this happens only after patch [1] has been
> > > upstreamed.
> > > 
> > > Here [2] you can see all the other toolchains built succesfully and only
> > > Openrisc fails after the patch provided by Stafford([1]).
> > > 
> > > [1]: http://patches-tcwg.linaro.org/patch/53151/
> > > [2]: https://gitlab.com/bootlin/toolchains-builder/-/jobs
> > 
> > OK, so the real problem is in a backport.  It isn't current mainline
> > binutils configure, which is what I was worried about.
> 
> ...it happens on mainline too but it can be solved by adding -std=c99 to
> CFLAGS.

Do you have an example of it happening on mainline? According to Alan, mainline
should not happen as we should be applying -std=c99 automatically.  If not we
can fix that.

> > BTW, thank you for posting a fix here, even if it isn't strictly
> > necessary for mainline.  Please note that I'm not advocating against
> > your patch.  If target maintainers want to keep their code compatible
> > with C89 that's fine by me.
> > 
> I didn't know about this since no other file failed building on C99. What it
> seems strange to me is that on buildroot binutils seem to be built without
> -std=c99

As mainline binutils is supposed to require c99 now.  I rather not change the
code but fix any issues with configure not setting flags.

I looked at ./configure.ac and I confirm that we have setup c99 flags.  But I
also notice in bfd/configure.ac that we define it again without c99, but that
should not matter as CC should already be defined.  Either way does the below
patch help?

diff --git a/bfd/configure.ac b/bfd/configure.ac
index 07a75ed1626..387c74152d0 100644
--- a/bfd/configure.ac
+++ b/bfd/configure.ac
@@ -34,7 +34,7 @@ dnl Default to a non shared library.  This may be overridden
by the
 dnl configure option --enable-shared.
 AC_DISABLE_SHARED
 
-AC_PROG_CC
+AC_PROG_CC_C99
 AC_GNU_SOURCE
 AC_USE_SYSTEM_EXTENSIONS

--

-Stafford


More information about the Binutils mailing list