Re: 3.0.1 release? (report on mingw)

[Michael Goffioul]

On Tue, Apr 8, 2008 at 8:48 AM, Tatsuro MATSUOKA <address@hidden> wrote:
> Hello
>
>  To test what Michae pointed out. I used lo-sysdep.cc in 3.0.1a.
>
>  I have confirmed the stream.
>  file-ops.h > str-vec.h > Array.h > lo-utils.h > windows.h (around line 69).
[snip]
>  I manually modified the config.h as
>
>  386 /* Define to 1 if you have the `LoadLibrary' function. */
>  387 #define HAVE_LOADLIBRARY  1 /* #undef HAVE_LOADLIBRARY */
>
>  After that lo-sysdep.cc was complied without problem.
>  So serious problem in mingw for is LoadLibrary (); check failes.

You have to be careful here and not mix up HAVE_LOADLIBRARY and
HAVE_LOADLIBRARY_API. These correspond to 2 different things in
the configure script:

1) HAVE_LOADLIBRARY is defined when the configure script detects
the presence of LoadLibrary; however the check is buggy and it is always
false, even on my system. I explained it in an earlier mail: LoadLibrary
per se does NOT exist, it's either LoadLibraryA or LoadLibraryW; LoadLibrary
is then simply #define'ed in some windows headers. The way the configure
check is built cannot deal with this situation because the generated
conftest.c does not include windows.h. In summary, on your platform,
HAVE_LOADLIBRARY should not be defined and that's normal; it's
the same for me.

2) HAVE_LOADLIBRARY_API is defined unconditionally by the configure
script (configure.in: around line 1467) on Win32 platform (cygwin, msvc and
mingw). So on your platform, HAVE_LOADLIBRARY_API *should* be
defined; if it is not, then there's a serious problem. You should then look
at $canonical_host_type variable within the configure script to see why it
does not match the "case" statement (see configure.in to see what I mean).

Now if you look at lo-utils.h, you'll see that windows.h inclusion is
dependent on HAVE_LOADLIBRARY_API; so it's point 2) above that
is important, and you can forget about point 1).

Hope this helps.

Michael.