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 core
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 p
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
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
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
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! The
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 http://buildbot.
