groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [address@hidden: macOS 12.6.3 and vasnprintf compilation failure]


From: Bruno Haible
Subject: Re: [address@hidden: macOS 12.6.3 and vasnprintf compilation failure]
Date: Tue, 07 Feb 2023 02:06:59 +0100

Hi Branden,

> A problem immediately arose on macOS 12.6.3.  It's our good friend
> vasnprintf again.  Logs are available on Savannah[2].
> 
> lib/vasnprintf.c:411:16: error: expected parameter declarator
> static_assert (sizeof (mp_limb_t) * CHAR_BIT == GMP_LIMB_BITS);
>                ^
> lib/vasnprintf.c:411:16: error: expected ')'
> lib/vasnprintf.c:411:15: note: to match this '('
> static_assert (sizeof (mp_limb_t) * CHAR_BIT == GMP_LIMB_BITS);
>               ^
> lib/vasnprintf.c:411:1: warning: type specifier missing, defaults to 'int' 
> [-Wimplicit-int]
> static_assert (sizeof (mp_limb_t) * CHAR_BIT == GMP_LIMB_BITS);
> ^
> lib/vasnprintf.c:415:16: error: expected parameter declarator
> static_assert (sizeof (mp_twolimb_t) * CHAR_BIT == GMP_TWOLIMB_BITS);
>                ^
> lib/vasnprintf.c:415:16: error: expected ')'
> lib/vasnprintf.c:415:15: note: to match this '('
> static_assert (sizeof (mp_twolimb_t) * CHAR_BIT == GMP_TWOLIMB_BITS);
>               ^
> lib/vasnprintf.c:415:1: warning: type specifier missing, defaults to 'int' 
> [-Wimplicit-int]
> static_assert (sizeof (mp_twolimb_t) * CHAR_BIT == GMP_TWOLIMB_BITS);
> ^

I can reproduce the issue on a macOS 12.5 machine (gcc104.fsffrance.org —
you can surely get an account there too).

The command
  $ make lib/vasnprintf.o V=1
shows me the compiler command line that failed:
depbase=`echo lib/vasnprintf.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
        cc -DHAVE_CONFIG_H -I. -I.. -I./src/include  -I../src/include -I../lib 
-I./src/include -I./lib -I/Users/haible/include -Wall  -g -O2 -MT 
lib/vasnprintf.o -MD -MP -MF $depbase.Tpo -c -o lib/vasnprintf.o 
../lib/vasnprintf.c &&\
        mv -f $depbase.Tpo $depbase.Po
...

Take this command, remove the -c and -o options, and instead add -E:

  $ cc -DHAVE_CONFIG_H -I. -I.. -I./src/include  -I../src/include -I../lib 
-I./src/include -I./lib -I/Users/haible/include -Wall  -g -O2 
../lib/vasnprintf.c -E > i

Since it looks like the 'static_assert' macro is not defined, and it
ought to be defined by <config.h> via <assert.h>, two questions arise:

1) Does <config.h> contain the boilerplate for including <assert.h>?
   config.h is found in src/include/config.h.
   Inspection shows: Yes, it does.

2) Does <assert.h> contain the boilerplate for defining 'static_assert'?
   Here's the problem: There are two assert.h files:
     $(builddir)/lib/assert.h        gnulib generated, contains the #define 
static_assert
     $(srcdir)/src/include/assert.h  groff-owned

   <assert.h> in the newest ISO C 23 standard is supposed to make
   'static_assert' available. [1]

   The problem is a combination of:

     - The groff-owned $(srcdir)/src/include/assert.h takes precedence
       over the one in $(builddir)/lib — due to the particular order of the
       -I options. This can be seen by looking into the 'i' file.

     - The groff-owned $(srcdir)/src/include/assert.h does not use
       #include_next <assert.h>; this would include the next <assert.h>,
       namely $(builddir)/lib/assert.h.

     - The groff-owned $(srcdir)/src/include/assert.h does not define
       'static_assert' by itself.

   So, to fix things, you need to either
     - change the -I options order, or
     - use #include_next <assert.h> if the compiler supports #include_next,
       otherwise #include <absolute_file_name_of_next_assert.h>, or
     - implement your own logic for defining 'static_assert' in C.

   Note: If you go by the first option, you may still get problems on
   those systems where /usr/include/assert.h defines 'static_assert' and
   thus gnulib's $(builddir)/lib/assert.h is just a wrapper without much
   added value. Namely, the lack of #include_next <assert.h> in groff's
   assert.h will prevent /usr/include/assert.h from being read.

Hope this helps. This is not a complete solution, but you get some ideas.

Bruno

[1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf






reply via email to

[Prev in Thread] Current Thread [Next in Thread]