[gnutls-devel] Building a MinGW port of GnuTLS 3.4.15

[Eli Zaretskii]

> From: Nikos Mavrogiannopoulos <nmav at gnutls.org>
> Cc: gnutls-devel at lists.gnutls.org
> Date: Wed, 05 Oct 2016 20:45:42 +0200
> 
> On Wed, 2016-10-05 at 10:29 +0300, Eli Zaretskii wrote:
> 
> > > > 3. libgnutls fails to link due to unresolved external rpl_fseek:
> > > > 
> > > >        CCLD     libgnutls.la
> > > >      opencdk/.libs/libminiopencdk.a(armor.o): In function
> > > > `armor_decode':
> > > >      d:\gnu\gnutls-3.4.15\lib\opencdk/armor.c:232: undefined
> > > > reference to `rpl_fseek'
> > > >      opencdk/.libs/libminiopencdk.a(stream.o): In function
> > > > `cdk_stream_seek':
> > > >      d:\gnu\gnutls-3.4.15\lib\opencdk/stream.c:1081: undefined
> > > > reference to `rpl_fseek'
> > > >    I reported this for 3.3.11 back in Dec 2014.
> > > I do not know about this issue or what could trigger it.
> > I'm sure I explained it back then: This is because gl/libgnu.a does
> > not compile fseek replacement in src/gl/fseek.c and src/gl/fseeko.c
> > (unlike src/gl/libgnu.a), but gl/stdio.h defines fseek to rpl_fseek,
> > which is defined in src/gl/fseek.c.
> > Let me know if something is still unclear about this.
> 
> Well, I understand what the issue is, what I have no idea how to
> address it on that particular case. Dealing with gnulib replacements is
> no fun, and the fact that it works with mingw64 does not add an
> incentive for me to figure that out. If you have a fix though I'll
> include it.

The fix I used is a hack: I simply #include'd the necessary source
files in ftell.c, which is compiled into libgnu.a.

> > > That does not seem to be the case in the mingw builds under fedora
> > > as
> > > shown above. Could that be something related to mingw vs mingw64?
> > No, it can't, AFAIK.  It's a general Windows issue: a DLL is looked
> > according to certain rules and order described here:
> >  https://msdn.microsoft.com/en-
> > us/library/windows/desktop/ms682586(v=vs.85).aspx
> > (only the "Desktop applications" part is relevant for this
> > discussion).  In a nutshell, Windows first looks in the same
> > directory
> > where the .exe file lives, then in the current directory, then along
> > the PATH (the other places are not relevant for this case).  The
> > just-built libgnutls DLL is in neither of these.
> > I don't think MinGW64 could affect this because this search happens
> > before the application code starts, it is part of the process of
> > loading the application by the Windows loader.
> 
> My understanding of the latest builds with libtool and mingw64 was that
> there is a placeholder .exe generated in src/ which probably as you say
> do the lib resolution and the actual exe lives in src/.libs/. I don't
> have the system I cross compile to verify but the build I referred in
> the previous post was using that structure for executables.

Yes, this is what happens in my build as well.

I don't know how to set that up, either.  I do know that other
projects that use libtol succeed in this, so maybe asking on the
libtool list will help?

Thanks.