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

[B. Scott Michel]

On 9/5/2013 1:36 AM, Tomasz Gajewski wrote:
> I've checked that this symbol is available in four built libraries:
>
> ./gnutls-3.2.3/lib/.libs/libgnutlsxx-28.dll
> ./gnutls-3.2.3/lib/.libs/libgnutls-xssl-0.dll
> ./gnutls-3.2.3/lib/.libs/libgnutls-28.dll
> ./gnutls-3.2.3/extra/.libs/libgnutls-openssl-27.dll
>
> but it is exported using def files only from:
>
> ./gnutls-3.2.3/lib/.libs/libgnutls-xssl-0.dll
> ./gnutls-3.2.3/extra/.libs/libgnutls-openssl-27.dll
>
>
> I don't know how those libraries are expected to be used (as replacements or
> some extension plugins) and in consequence I don't know if how this should
> be fixed.
>
> 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?

".def" symbol export files should be avoided, if at all possible. Use 
the '.dll.a' archives -- libtool ensures that the '.dll.a' files are 
properly generated.

However, this requires that the gnutls library do two things: (a) use 
symbol visibility attributes in the code to mark imported/exported 
functions, (b) arrange for the "right" symbol visibility when compiling 
the library vs. compiling non-library/application code. For the WinXX 
platform, import vs. export preprocessor header file management isn't 
complicated, but can be messy. There is a subtle benefit for the Linux 
and shared object platforms: gnutls can hide symbols and generally speed 
up dynamic linking (as opposed to making all symbols visible, which is 
the default.)

The patch to pull off (a) and (b) is not small and it isn't incremental. 
Additionally, there's some gnulib hacking foo required to expose 
symbols, since gnulib doesn't natively include symbol visibility attributes.


-scooter