Hi, Simon Josefsson <[EMAIL PROTECTED]> writes:
> Anyway, I don't see any harm in setting the compiler in C99 mode if the > compiler supports it. One possible problem is that you end up writing C99 code, using C99-specific things like, say, C++-style comments, declarations not at the beginning of a block, etc. These things will break with non-C99 compilers. > GnuTLS optionally use several C99 features, such > as __func__, CPP macros with flexible number of parameters, stdbool.h. C99 headers can usually be used even without a C99 compiler (well, provided they're available, of course). > If the compiler doesn't supports those, we'll disable those features or > use our gnulib-workarounds, which seems sub-optimal. We want our code > to work with C99. To "work with C99" or to "require C99"? Surely either is acceptable, but I have the impression that there's a slow movement towards the latter. > I still don't see how this problem occur though. Exactly how is the > gmpz_abs symbol pulled into guile/src/*.o files? If gmpz_abs is inline > in gmp.h, should that be inlined into the guile code? Does setting the > compiler in gnu99 mode also set the linker in a different mode, that > causes this problem? <libguile.h> includes <libguile/numbers.h>, which in turn includes <gmp.h>, which contains declarations and "extern inline" definitions (in the "GNU89" sense). Why it `__gmpz_abs' ends up as a global, exported symbol in the `.o' objects produced on MacOS X, I have now idea. On GNU/Linux with GCC 4.2.3, it never happens, whether compiled with `-std=c99' or not. Help is welcome. :-) Thanks, Ludovic. _______________________________________________ Help-gnutls mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnutls
