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

Simon Josefsson simon at josefsson.org
Wed Mar 19 16:01:43 CET 2008


David Reiser <dbreiser at gmail.com> writes:

> On Mar 19, 2008, at 8:03 AM, Ludovic Courtès wrote:
>
>> Hi,
>>
>> David Reiser <dbreiser at gmail.com> writes:
>>
>>> $ nm -g bar.o | grep mpz_abs
>>>         U ___gmpz_abs
>>
>> Hmm, can you do the same on the offending files, i.e.,
>>
>>  $ for i in errors core; do
>>    nm -g ./guile/src/.libs/libguile_gnutls_v_1_la-$i.o | grep mpz_abs
>>    done
>>
>> Thanks,
>> Ludovic.
>
> 00000000 T ___gmpz_abs
> 00000000 T ___gmpz_abs
>
> and if I add utils to the list, it's there the same way, so I don't
> know why the linker isn't complaining about that also.
>
> The 10.5 linker does have problems (or at least differences involving)
> inline functions. For glib 2.16.1, we have to force
> #  define G_INLINE_FUNC static inline
> to get some things depending on glib to compile.

I have some vague memory about reading that the semantics of 'inline'
has changed recently.  If you don't mark inline functions static, they
will be exported as well, because they may be needed in other files.
That would explain this problem.  I may be remembering incorrectly, but
it may be that this new behaviour is actually correct.

I can't find this symbol in the GnuTLS sources, so I would suspect it is
used in Guile?

This reminds me, there is a bunch of warnings about use of inline
functions in the gnutls-guile code, such as:

core.c:1335: warning: function ‘set_certificate_file’ can never be inlined because it uses alloca (override using the always_inline attribute)
core.c:1335: warning: inlining failed in call to ‘set_certificate_file’: function not inlinable

I don't think this is related, though.

/Simon





More information about the Gnutls-help mailing list