Re: Possible issue with static win32 gsasl

[Lothar May]

Hi Simon,

2010/9/27 Simon Josefsson <address@hidden>:
> Lothar May <address@hidden> writes:
>> I wanted to switch from gsasl 1.4.2 to 1.5.0 using the prebuilt static
>> mingw (win32) libraries.
(snip)
>>
>> ..\gsasl\lib/libshishi.a(gc-libgcrypt.o): In function `gc_done':
>> /home/jas/gnutls4win/build/shishi-0.0.43/gl/../../../src/shishi-0.0.43/gl/gc-lib
>> gcrypt.c:66: multiple definition of `gc_done'
>> ..\gsasl\lib/libgsasl.a(gc-libgcrypt.o):/home/jas/gnutls4win/build/gsasl-1.5.0/l
>> ib/gl/../../../../src/gsasl-1.5.0/lib/gl/gc-libgcrypt.c:66: first defined 
>> here
>>
>> Does anyone know what the problem might be?
(snip)
> Unfortunately this is a known problem with static libraries -- both
> GSASL and Shishi uses the same name for some internal functions (mostly
> for shared gnulib code).  For shared libraries, all internal symbols are
> hidden, but for static libraries, this is not possible and you get name
> clashes when linking.  There are workarounds for this (prefix all
> internal symbols with _gsasl_ or _shishi_ respectively) that Bruno
> Haible has suggested, but I have not yet had time to evaluate and
> implement it for GNU SASL.
>
> I think the simplest solution for you meanwhile is to rebuild GNU SASL
> without Shishi -- or do you need GSS-API/GS2 support?  If so, you could
> try to use GNU SASL with MIT KfW as the GSS-API library, see my recent
> announcement and this build page: http://josefsson.org/gsasl4win/
>
> Alternatively, use shared libraries!

Thanks for the feedback! Also, thanks for the hint in the announcement
that 1.5.x is still experimental. At this time I do not need Kerberos,
but I would like to stick to the official builds if possible. So when
I switch to 1.5.x, I will use the shared libraries - that should be
totally fine.

Thanks again,
Lothar