Re: Problem with library images on Windows (again)

["Eli Zaretskii" <eliz@gnu.org>]

> Date: Fri, 20 May 2005 12:42:09 +0200
> From: Juanma Barranquero <lekktu@gmail.com>
> 
> Unless I'm wrong, the issue is not how the functions are defined on
> the headers, because we don't statically link against the functions,
> but how are they compiled in the library and how do we define the
> fn_XXX pointers to them.

It's the issue with both: the prototypes in the header files should be
consistent with how the functions were compiled, since those
prototypes are the only way for the compiler to know how the functions
were compiled.  If it doesn't know that, it might produce wrong code.

> In this case, the GnuWin32 TIFF 3.7.2
> libraries seem to be compiled to use C calling conventions, but we
> declare pointers to them with DEF_IMGLIB_FN, which says unequivocally
> that they're FARPROC (i.e, "pascal").

That seems to be the problem.  What I still don't get is how come the
same declaration that uses FARPROC works for the MinGW build?  Can you
figure this out?

If we know this, we could fix the DEF_IMGLIB_FN macro so that it does
TRT for both compilers, e.g., by using __MINGW__ condition.

> The TIFF page in gnuwin32.sourceforge.net says:
> 
> "The GnuWin32 distribution comes in two versions. The ordinary version
> uses the standard Unix equivalents, such as fopen and read, for input
> and output, the other version (Tiff-win32) uses the Win32 API
> functions, such as CreateFile and ReadFile, for input and output. The
> ordinary version (Tiff) is more suitable for porting Unix programs,
> the Win32-API version is more suitable for writing Win32 programs."

This doesn't say anything about the calling conventions, just about
the inner workings of the functions.  So I'm not surprised that both
versions have the same effect.