Frank Warmerdam wrote:
> configure:7653: checking for GDALOpen
> configure:7679: gcc -o conftest.exe -g -I/usr/local/include -I/c/progra~1/GnuWin32/include -I/c/OSGeo4W/include -Wl,--export-dynamic,--enable-runtime-pseudo-reloc -L/usr/local/lib -L/c/progra~1/GnuWin32/lib -L/c/OSGeo4W/lib conftest.c /c/OSGeo4W/lib/gdal_i.lib -L/c/OSGeo4W/lib -lpng -lz 1>&5
> C:/DOCUME~1/glynn/LOCALS~1/Temp/ccAxbaaa.o(.text+0x2b): In function `main':
> C:/msys/1.0/home/glynn/grass/configure:7673: undefined reference to `GDALOpen'
> collect2: ld returned 1 exit status
>
> But I've figured it out. The GDAL library was built to use "stdcall",
> which isn't compatible with autoconf tests (AC_CHECK_FUNC etc).
>
> The autoconf AC_CHECK_FUNC test doesn't use any headers, so it doesn't
> know that the function uses the "stdcall" convention, and also doesn't
> know that its argument list totals 8 bytes (hence the _GDALOpen@8
> name).
>
> We would have to write a custom test, using AC_TRY_LINK on a complete
> test program (which includes headers). We would also need to work
> around the CPL_STDCALL definition in cpl_port.h:
>
> #ifndef CPL_STDCALL
> #if defined(_MSC_VER) && !defined(CPL_DISABLE_STDCALL)
> # define CPL_STDCALL __stdcall
> #else
> # define CPL_STDCALL
> #endif
> #endif
>
> which only uses __stdcall for MSVC.
Glynn,
Hmm, I thought I had dealt with this. The /c/osgeo4w/include/cpl_config.h
file should start with:
/* We define this here in general so that a VC++ build will publically
declare STDCALL interfaces even if an application is built against it
using MinGW */
#ifndef CPL_DISABLE_STDCALL
# define CPL_STDCALL __stdcall
#endif
Okay.
The mingw build *should* properly respect this stdcall definition,
and it works for me. Is there any chance you are picking up some other
cpl_config.h instead of the one in /c/osgeo4w/include? Could you
confirm that the /c/osgeo4w/include/cpl_config.h on your system starts
with the stdcall stuff?
It does. but that doesn't help with the configure checks, which don't
use any headers. The test program just provides a local declaration:
char GDALOpen();
This doesn't account for the calling convention. Nor does it account
for the size of the argument list, which is appended to the name of
any functions which use the stdcall convention (as the callee cleans
up the stack, the caller must push exactly the right number of bytes,
otherwise the stack won't be restored correctly, causing a crash).
The actual test program (conftest.c) which is compiled and linked by
autoconf's AC_CHECK_FUNC macro is:
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
which can conflict with char GDALOpen(); below. */
#include <assert.h>
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char GDALOpen();
int main() {
/* The GNU C library defines this for functions which it implements
to always fail with ENOSYS. Some functions are actually named
something starting with __ and the normal name is an alias. */
#if defined (__stub_GDALOpen) || defined (__stub___GDALOpen)
choke me
#else
GDALOpen();
#endif
; return 0; }
> Or we could just compile GDAL ourselves from source using MinGW, which
> is probably the best solution.
This is exactly what I'm trying to avoid!
I'd also like to avoid it, but I'm wondering if the hassle factor is
going to be too high. The main issue is avoiding the need for
per-platform sections in configure and elsewhere. As a general rule,
the Unix version tends to be where most of the development occurs, and
also where most of the testing occurs.
The more special cases required for Windows, the greater the chance
that the latest version won't build on Windows. It doesn't help that
the luckless user will be largely on their own, as Windows developers
tend to be scarce and relatively inexperienced, and the Unix
developers typically don't understand, can't test and/or don't
especially care.
> Although I would rather stick to
> "official" binaries where possible, in this case it's likely to be
> more trouble than it's worth.
>
> Note that PROJ doesn't use stdcall, nor do any of the GnuWin32
> libraries, nor MinGW's own libraries (obviously the import libraries
> for the Windows API do, as that's what Windows' own DLLs use).
>
> For the most part, using __stdcall is a bad idea. Modern computers
> have rather more than 640KiB of RAM, so shaving a few bytes from each
> function call really isn't that important any more.
stdcall is used so that the GDAL functions can be more easily called
from VB6 and/or delphi as I recall. It is not done for efficiency
purposes.
Okay.
>> To get proj to work, I found I had to copy /c/osgeo4w/lib/proj_i.lib to
>> /c/osgeo4w/lib/libproj.a.
>
> I just added /c/OSGeo4W/bin to the --with-libs= argument, so it links
> directly against the DLL.
I was not aware that this was possible.
It's quite common for Unix ports not to bother with import libraries
(e.g. GRASS doesn't create them; modules just link directly against
the DLLs). AFAICT, import libraries are largely an artifact of
importing symbols by ordinal (which, again, was originally done to
save a miniscule amount of space, by eliminating the need to have a
symbol table in the actual DLL).
> That isn't necessarily a problem (msvcrt.dll should already be present
> in Windows' system directory), but some people might get bitten the
> same way.
>
> Anyhow, I'd suggest that we use OSGeo4W's PROJ library, GnuWin32 for
> most of the other libraries, and compile GDAL ourselves, along with
> the hacked XDR library (there doesn't appear to be a standard binary
> for this; GnuWin32's version of libc doesn't appear to have these
> functions).
Ah, I mistook this email exchange to be an interest in actually packaging
wingrass for OSGeo4W. I see it is not.
I'll return to my corner and wait patiently in the hopes someone shows more
interest participating in OSGeo4W.
Well, I do have some interest, but right now I'm more concerned about
being able to build GRASS on Windows with a minimum of effort[1]. We
can't package what we don't have.
[1] If we can make it really easy, we might even get new volunteers
faster than the existing ones get fed up. Until we get to that point,
the number of active Windows developers at any given time is likely to
continue to oscillate between zero and one.
--
Glynn Clements <glynn@gclements.plus.com>
