Re: stdarg: don't put compiler in gnu99 mode by default

[Bruno Haible]

Simon Josefsson wrote:
> The problem appears
> to be conflicting linker behaviour for 'extern inline' and a problem
> with the Mac OS X linker.  See:
> 
> http://thread.gmane.org/gmane.network.gnutls.general/1061/focus=1136

It has to do with 'extern inline', and it has to do with MacOS X. I assume
it's the same cause as for the 'argp' failures (see the other mail). But

  1) By looking at the .s file that the compiler generates, I found that the
     problem is in the compiler/preprocessor, not in the linker.

  2) Additionally, if your user has not gmp >= 4.2.2 installed, it will also
     fail, because versions before gmp-4.2.2 were assuming the old GNU C meaning
     of 'inline'.

$ diff -c gmp-4.2.1/gmp-h.in gmp-4.2.2/gmp-h.in 
*** gmp-4.2.1/gmp-h.in  Tue Apr 11 20:10:15 2006
--- gmp-4.2.2/gmp-h.in  Mon Sep  3 18:05:40 2007
...
***************
*** 416,426 ****
     inline" would be an acceptable substitute if the compiler (or linker)
     discards unused statics.  */
  
! /* gcc has __inline__ in all modes, including strict ansi.  Give a prototype
!    for an inline too, so as to correctly specify "dllimport" on windows, in
!    case the function is called rather than inlined.  */
  #ifdef __GNUC__
  #define __GMP_EXTERN_INLINE      extern __inline__
  #define __GMP_INLINE_PROTOTYPES  1
  #endif
  
--- 414,430 ----
     inline" would be an acceptable substitute if the compiler (or linker)
     discards unused statics.  */
  
!  /* gcc has __inline__ in all modes, including strict ansi.  Give a prototype
!     for an inline too, so as to correctly specify "dllimport" on windows, in
!     case the function is called rather than inlined.
!     GCC 4.3 and above with -std=c99 or -std=gnu99 implements ISO C99
!     inline semantics, unless -fgnu89-inline is used.  */
  #ifdef __GNUC__
+ #ifdef __GNUC_STDC_INLINE__
+ #define __GMP_EXTERN_INLINE extern __inline__ __attribute__ ((__gnu_inline__))
+ #else
  #define __GMP_EXTERN_INLINE      extern __inline__
+ #endif
  #define __GMP_INLINE_PROTOTYPES  1
  #endif
  
***************
*** 512,519 ****
--- 516,525 ----
  
  #if defined (__cplusplus)
  extern "C" {
+ #ifdef _GMP_H_HAVE_FILE
  using std::FILE;
  #endif
+ #endif
  
  #define mp_set_memory_functions __gmp_set_memory_functions
  __GMP_DECLSPEC void mp_set_memory_functions __GMP_PROTO ((void *(*) (size_t),
***************
*** 2168,2174 ****
  /* Major version number is the value of __GNU_MP__ too, above and in mp.h. */
  #define __GNU_MP_VERSION 4
  #define __GNU_MP_VERSION_MINOR 2
! #define __GNU_MP_VERSION_PATCHLEVEL 1
  
  #define __GMP_H__
  #endif /* __GMP_H__ */
--- 2174,2180 ----
  /* Major version number is the value of __GNU_MP__ too, above and in mp.h. */
  #define __GNU_MP_VERSION 4
  #define __GNU_MP_VERSION_MINOR 2
! #define __GNU_MP_VERSION_PATCHLEVEL 2
  
  #define __GMP_H__
  #endif /* __GMP_H__ */

> The current solution in stdarg for the va_copy problem seems ugly to me.
> For example, it doesn't test for a missing feature before applying a
> workaround.  Can't we make the code do a feature-test, so it only puts
> the compiler in gnu99 mode if va_copy doesn't work?

I don't think it's a good fix to make less packages build in gnu99 mode.
gnu99 is the present. The gnu89 or c89 modes are legacy. We therefore need
to make the gnu99 mode work, fixing whatever problems we encounter.

I hope my patch does it. Your user should retest after he installed gmp-4.2.2
and after you rebuilt a new snapshot using current gnulib.

Bruno