Re: Possible issue with static win32 gsasl

[Simon Josefsson]

Lothar May <address@hidden> writes:

> Hi,
>
> I wanted to switch from gsasl 1.4.2 to 1.5.0 using the prebuilt static
> mingw (win32) libraries. However, it seems to require that I link to
> libshishi, which is included, but when I do so I get a lot of
> duplicate symbols like this:
>
> ..\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? Am I doing something
> wrong? I also link against the gnutls static release with libgcrypt
> (separately), but that does not seem to be listed here in the
> conflict.

Hi Lothar!

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!

/Simon