Andrey Kiselev kirjoitti:
On Wed, Oct 29, 2008 at 02:04:44PM +0200, Ari Jolma wrote:
I've set up a buildslave, which builds GDAL from a fresh checkout of
the trunk in Windows using the MSYS environment. Currently the build
is quite lean and only Perl bindings are built in addition to the
The wrappers seemed to build with Python 2.4 without other changes than
uncommenting libraries = gdal in setup.cfg. setup.py seems to set gdal_i
by default in windows.
The autotest dumps core in usgsdem.py test 4 (the culprit is memcpy in
MEMRasterBand::IReadBlock), but I'm not sure if I have
Ari,
fopr the crash in MEMRasterBand::IReadBlock(), I would suspect that
CPLScanPointer doesn't do its job rightly when compiled in MSYS environment.
The function looks currently like :
/* */
/* On MSVC we have to scanf
On Wed, Oct 29, 2008 at 02:04:44PM +0200, Ari Jolma wrote:
I've set up a buildslave, which builds GDAL from a fresh checkout of
the trunk in Windows using the MSYS environment. Currently the build
is quite lean and only Perl bindings are built in addition to the core
dll and apps. Only Perl
Andrey Kiselev wrote:
Otherwise of that bug Python stuff should be perfectly compilable and
usable with the official binary Python distribution.
At least with python2.5 I'm not sure about 2.6, but earlier pythons
required some patching to work with MingGW binaries.
-Chris
--
Christopher
All,
I've set up a buildslave, which builds GDAL from a fresh checkout of the
trunk in Windows using the MSYS environment. Currently the build is
quite lean and only Perl bindings are built in addition to the core dll
and apps. Only Perl tests are run.
The slave is listed on
Ari Jolma wrote:
All,
I've set up a buildslave, which builds GDAL from a fresh checkout of the
trunk in Windows using the MSYS environment. Currently the build is
quite lean and only Perl bindings are built in addition to the core dll
and apps. Only Perl tests are run.
Ari,
Excellent!
