[Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2

[Ludovic Courtès]

Hi,

Simon Josefsson <simon at josefsson.org> 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.