Glynn Clements wrote:
I've tried changing it to that, with the same result:
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 [EMAIL PROTECTED]
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
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?
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!
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.
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.
I also had to remove the msvcrt.dll from the bin directory, as that
caused -L/c/OSGeo4W/bin to fail (even if you didn't actually use any
libraries) due to multiple definitions of _onexit() and atexit().
I think you are barking up the wrong tree here, and there should be
no reason to remove msvcrt.dll from the bin directory.
No, that's definitely necessary if the bin directory is in the library
path (e.g. for linking directly against DLLs). Otherwise, it won't
link even the most trivial programs:
$ cat foo.c
int main(void)
{
return 0;
}
$ gcc foo.c
$ gcc foo.c -L/c/osgeo4w/bin
d000007.o(.text+0x0): multiple definition of `_onexit'
/mingw/lib/crt2.o(.text+0x2d0):crt1.c: first defined here
d000010.o(.text+0x0): multiple definition of `atexit'
/mingw/lib/crt2.o(.text+0x2c0):crt1.c: first defined here
collect2: ld returned 1 exit status
$ mv /c/osgeo4w/bin/{,x}msvcrt.dll
$ gcc foo.c -L/c/osgeo4w/bin
Well, then perhaps the /bin directory should not be in the library
path!
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.
Regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGeo, http://osgeo.org
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
