gnutls-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problem with cross build for windows on linux with shared libraries


From: Eli Zaretskii
Subject: Re: Problem with cross build for windows on linux with shared libraries
Date: Thu, 05 Sep 2013 12:26:14 +0300

> From: Tomasz Gajewski <address@hidden>
> Date: Thu, 5 Sep 2013 08:36:10 +0000 (UTC)
> 
> I'm experimenting with build for windows using mingw cross compiler. During
> build I get link error during linking psktool.exe due to missing symbol
> rpl_localtime.

Symbols of the form rpl_FUNC usually come from gnulib replacements.
So this symbol should have been resolved by linking against gnulib.
The link command you show:

> libtool: link: i686-pc-mingw32-gcc -std=gnu99 -g -O2 -o .libs/psktool.exe
> psk.o  ../lib/.libs/libgnutls.dll.a 
> -L/home/tomga/external/mxe/usr/i686-pc-mingw32/lib -lz -lhogweed -lnettle 
> /home/tomga/external/mxe/usr/i686-pc-mingw32/lib/libgmp.dll.a -lcrypt32 
> ./.libs/libcmd-psk.a ../gl/.libs/libgnu.a 
> /home/tomga/external/mxe/usr/i686-pc-mingw32/lib/libiconv.dll.a -lws2_32 
> ../src/libopts/.libs/libopts.a 
> /home/tomga/external/mxe/usr/i686-pc-mingw32/lib/libpcreposix.dll.a 
> /home/tomga/external/mxe/usr/i686-pc-mingw32/lib/libpcre.dll.a 
> -L/home/tomga/external/mxe/usr/i686-pc-mingw32/lib

already links against gnulib, see ../gl/.libs/libgnu.a above.  So the
problem seems to be that gnulib is mentioned on the link command line
_before_ libopts.a.  Re-arranging the order of the libraries so that
libgnu.a is after libopts.a should fix the problem.

Actually, I think libiconv and -lws2_32 should also be closer to the
end of the link command line.

> I see two ways of fixing:
> 
>   - extend def file for libgnutls-28.dll with rpl_* functions
>   - add one of those libraries which have rpl_* functions exported to link
> command for psktool.exe
> 
> What do you think about this?

I don't maintain GnuTLS, so please wait for others to speak up.  But,
FWIW, it sounds wrong to me to export rpl_* functions from shared
libraries, because they are replacements for missing or buggy
implementations on the target platforms.  So I think _none_ of the
libraries should export them, and using the fact that some of them do
(surely, by some accident) is not a good idea.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]