[Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2
ludo at gnu.org
Thu Mar 27 15:04:01 CET 2008
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
> 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.
>> 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.
> 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...
More information about the Gnutls-help