Re: m4-1.4.19 not C99 clean ?

[Eric Blake]

Adding bug-gnulib, since...

On Mon, Sep 13, 2021 at 12:36:12AM -0400, Dennis Clarke wrote:
> 
> Not sure if this is a bug if m4 is not supposed to be C89 or C99 clean
> however I see :
> 
> .
> .
> .
> /opt/bw/bin/gmake  all-am
> gmake[3]: Entering directory
> '/opt/bw/build/m4-1.4.19_sunos5.10_sparcv9.001/lib'
> source='asyncsafe-spin.c' object='asyncsafe-spin.o' libtool=no \
> DEPDIR=.deps depmode=dashXmstdout /opt/bw/bin/bash ../build-aux/depcomp \
> /opt/developerstudio12.6/bin/c99  -I.   -I/opt/bw/include
> -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO
> -D_FILE_OFFSET_BITS=64 -D_XOPEN_SOURCE=600 -D_REENTRANT  -Xc
> -errtags=yes -errwarn=%none -m64 -xarch=sparc -xO0 -g -xs -errfmt=error
> -erroff=%none -errshort=full -xstrconst -xildoff -xmemalign=8s
> -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none
> -xbuiltin=%none -xunroll=1 -Qy -xdebugformat=dwarf -c -o
> asyncsafe-spin.o asyncsafe-spin.c
> "asyncsafe-spin.c", line 213: error: undefined symbol: asm
> "asyncsafe-spin.c", line 213: error: syntax error before or at: volatile
> "asyncsafe-spin.c", line 238: error: undefined symbol: asm
> "asyncsafe-spin.c", line 238: error: syntax error before or at: volatile
> c99: acomp failed for asyncsafe-spin.c

...asyncsafe-spin.c comes from gnulib.

> gmake[3]: *** [Makefile:2869: asyncsafe-spin.o] Error 2
> gmake[3]: Leaving directory
> '/opt/bw/build/m4-1.4.19_sunos5.10_sparcv9.001/lib'
> gmake[2]: *** [Makefile:2481: all] Error 2
> gmake[2]: Leaving directory
> '/opt/bw/build/m4-1.4.19_sunos5.10_sparcv9.001/lib'
> gmake[1]: *** [Makefile:2018: all-recursive] Error 1
> gmake[1]: Leaving directory '/opt/bw/build/m4-1.4.19_sunos5.10_sparcv9.001'
> gmake: *** [Makefile:1974: all] Error 2
> 
> Where we see the asm usage that sort of says "not C99 here".
> 
> However std9899:2011 seems to be just fine.
> 
> So are we C11 here only ?

I'm not sure how much of gnulib still tries to cater to C89,
vs. assuming C99.  But if there is an obvious fix for your compiler,
we're likely to use it.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org