[Help-gnutls] Re: gnutls 2.3.4 doesn't copile using MinGW

[Simon Josefsson]

Massimo Gaspari <massimo.gaspari at alice.it> writes:

>> In particular, do you want --disable-shared?  Building a DLL should be
>> possible.
>>
>>   
>
> I don't need and I prefer static libraries only.

Ok.

> I used
>
> --disable-dev-random
>
> because otherwise (please correct me if I'm wrong) I need /dev/random without that option
> (Windows XP and/or Vista). Is it correct?  Can I use /dev/random on Windows platform as well?
> Or is  --disable-dev-random needed on Windows?
> As you know I'm a GnuTls beginner. So please be patient.. :-)

Actually, since you use libgcrypt, that parameter doesn't do anything.
The --disable-dev-random flag is only used if you also add
--with-builtin-crypto but that isn't well supported, see README.  You
can safely remove it.

> Just to tell you the whole story, the libgpgcrypt was configured using
>
> ./configure --disable-shared --disable-rpath
>
> But I don't think libgpg-error is involved in the reported issue.

Agreed.

> I re-tried to compile gnutls and after the error message I made "
> touch lib/libgnutls-26.def" . Then I got the following error message
...
> I made "touch libextra/libgnutls-openssl-26.def". Then the same for
> libgnutls-extra-26.def, after another  "touch" I got
...

I see 2.3.5 fixed these for you, good.

> /bin/sh ../libtool --tag=CC   --mode=link gcc -std=gnu99 -pipe
> -I/usr/local/include -O2 -Wno-pointer-sign   -o gnutls-serv.exe
> serv-gaa.o serv.o common.o select.o ../lib/libgnutls.la
> -L/usr/local/lib -lgcrypt -lgpg-error  ../gl/libgnu.la -lws2_32
> libtool: link: gcc -std=gnu99 -pipe -I/usr/local/include -O2
> -Wno-pointer-sign -o gnutls-serv.exe serv-gaa.o serv.o common.o
> select.o  ../lib/.libs/libgnutls.a -L/usr/local/lib
> ../gl/.libs/libgnu.a /usr/local/lib/libgcrypt.a
> /usr/local/lib/libgpg-error.a -lws2_32
> C:/msys/1.0/local/lib/libgcrypt.a(libgcrypt_la-missing-string.o):missing-string.c:(.text+0x30):
> multiple definition of `_vasprintf'
> ../lib/.libs/libgnutls.a(vasprintf.o):vasprintf.c:(.text+0x0): first
> defined here
> collect2: ld returned 1 exit status
> make[3]: *** [gnutls-serv.exe] Error 1
> make[3]: Leaving directory `/home/Massimo/gnutls-2.3.4/src'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/home/Massimo/gnutls-2.3.4/src'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/Massimo/gnutls-2.3.4'
> make: *** [all] Error 2
>
> This time "touch" can't help :-).
>
> Any other suggestion?

Ouch, this isn't a fun problem. :-(

I've known about this for some time, but don't know a good solution.

The problem is that libgcrypt defines a 'vasprintf' function, and it is
stored in the static library.

GnuTLS also defines a 'vasprintf' function.

When you use shared libraries, this isn't a problem because the
namespaces won't collide, so the symbols will just be hidden.

But with static libraries, both symbols are there, and they collide.

The interesting thing is that my Windows builds (see
<http://josefsson.org/gnutls4win/>) do not trigger this problem.  I
build both shared and static libraries.  So maybe you could see if
building shared libraries for some strange reason makes the static
library link for you?

I'm not sure what the best solution is.  Possibly 'vasprintf' shouldn't
be exported, but with static libraries, I don't think that is possible.
All symbols used are exported.  So maybe the symbol needs to be renamed.

This is a general problem with linking multiple libraries that use
modules from gnulib, so I should bring this up on the gnulib list.

> Nevertheless during compilation I got the followin warnings
>
> libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H
> -I. -I../.. -I../../lgl -I../../lgl -I../../libextra
> -I../../lib/minitasn1 -I../../libextra/openpgp/
> -I../../libextra/opencdk -I../../lib -I../../includes -I../../includes
> -I/usr/local/include -pipe -I/usr/local/include -O2 -Wno-pointer-sign
> -MT x509.lo -MD -MP -MF .deps/x509.Tpo -c x509.c -o x509.o
> x509.c: In function '_gnutls_x509_crt_cpy':
> x509.c:95: warning: implicit declaration of function 'alloca'
> x509.c:95: warning: incompatible implicit declaration of built-in
> function 'alloca'
> x509.c: In function 'gnutls_x509_crt_get_fingerprint':
> x509.c:1965: warning: incompatible implicit declaration of built-in
> function 'alloca'
> x509.c: In function 'gnutls_x509_crt_get_key_id':
> x509.c:2160: warning: incompatible implicit declaration of built-in
> function 'alloca'
> mv -f .deps/x509.Tpo .deps/x509.Plo
>
>
> The same warning is present for other files as well. Do you need a
> full list?

No, that error is sufficient for me.

Does your system have alloca.h?  What does ./configure say about alloca?

I'm not sure it is worth the problems to use alloca.  Even if we get it
to compile, there may be subtle size restrictions on it as well which
can cause failures at run-time instead.

> I was unable to find a new daily snapshot. May be it isn't available
> yet. I'm going to try as soon as the new snapshot is available.

It should be available now, but won't fix your two more important
problems.

/Simon