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

[Nikos Mavrogiannopoulos]

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.

> > 5. Test programs fail to run because they don't find the
> > > libgnutls
> > >    shared library (which was not installed yet).  I fixed that by
> > >    manually adding the directories with the DLLs to PATH, but I
> > > think
> > >    the test suite should do that, because if a previous version
> > > of the
> > >    same DLL is installed, the tests will silently use it instead
> > > of
> > >    the one in the source tree, which might cause incorrect
> > > results and
> > >    subtle failures.
> > 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.

> > > ${prefix}/bin
> > >    directory, whereas it should install them in ${prefix}/lib, I
> > >    think.
> > No opinion about that. I have no idea what are the conventions for
> > win
> > libraries. If you think that libdir is a better location I'll
> > update
> > the Makefile.am.
> bindir is definitely wrong.  The other *.def files I have are in
> libdir, so yes, I think it's a better place.

Done, thanks.

regards,
Nikos