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

[Ludovic Courtès]

Hi Simon,

Simon Josefsson <simon at josefsson.org> writes:

> ludo at gnu.org (Ludovic Courtès) writes:

>> 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.
>
> Yes, but anything like that would be bugs.  We still target C89 + POSIX
> sockets.  Gcc's default mode is gnu89 (I think?), which does permit some
> things from C99, so we have had this problem forever.

Compiling with `-std=c99' makes it harder to catch these "bugs".

> Unfortunately, I think it is too early to require C99.  A lot of
> embedded and less capable systems need gnutls, and they barely have C89
> support even these days.

Agreed.

>> Why it `__gmpz_abs' ends up as a global, exported symbol in the `.o'
>> objects produced on MacOS X, I have now idea.
>
> As far as I can tell, it would only happen if some code in gnutls uses
> some guile declaration that implicitly calls gmpz_abs.

Reports I've seen about the `G_INLINE_FUNC' issue in Glib (which is a
similar problem) seem to imply that something's wrong with Apple's
linker that prevents "extern inline" from working properly.

> 'extern inline' means, I think, that stand-alone object code is still
> generated and can be used by external code.  So any code that use calls
> mpz_abs would declare an external symbol as well.  However, it seems to
> me that this should only be a weak symbol, so I don't understand how
> there could be a symbol collision.

Indeed.

> Hm.  There is actually some interesting discussion in gmp.h:
>
> /* The following are provided as inlines where possible, but always exist as
>    library functions too, for binary compatibility.
>
>    Within gmp itself this inlining generally isn't relied on, since it
>    doesn't get done for all compilers, whereas if something is worth
>    inlining then it's worth arranging always.
>
>    There are two styles of inlining here.  When the same bit of code is
>    wanted for the inline as for the library version, then __GMP_FORCE_foo
>    arranges for that code to be emitted and the __GMP_EXTERN_INLINE
>    directive suppressed, eg. mpz_fits_uint_p.  When a different bit of code
>    is wanted for the inline than for the library version, then
>    __GMP_FORCE_foo arranges the inline to be suppressed, eg. mpz_abs.  */

Another possible investigation area...

Thanks,
Ludovic.