[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.