Hi,
I've probably missed something, but while 1.6.3 builds OK with EXPAT for
GPX on MSYS, 1.7.0 revision 18238 doesn't. The problem is in:
libtool: compile: g++ -O2 -Wall -I.. -I../.. -I/usr/local/include
-I/home/s1155 /gdal_svn/gdal/port -I/home/s1155/gdal_svn/gdal/gcore
Roger,
this is weird indeed as I use daily MSYS on trunk... I'd bet that you have an
installed version of cpl_string.h in /usr/local/include that corresponds to the
1.6.3 version that didn't have the CPLIsUTF8 and CPLForceToASCII symbols. If
you've done a make install when building 1.6.3 before,
On Thu, 10 Dec 2009, Even Rouault wrote:
Roger,
this is weird indeed as I use daily MSYS on trunk... I'd bet that you have an
installed version of cpl_string.h in /usr/local/include that corresponds to the
1.6.3 version that didn't have the CPLIsUTF8 and CPLForceToASCII symbols. If
you've
On Thu, 10 Dec 2009, Roger Bivand wrote:
On Thu, 10 Dec 2009, Even Rouault wrote:
Roger,
this is weird indeed as I use daily MSYS on trunk... I'd bet that you have
an
installed version of cpl_string.h in /usr/local/include that corresponds to
the
1.6.3 version that didn't have the
I am trying to build gdal on SUSE LINUX Enterprise Server 10 and I get the
following error. I have tried 1.6.3 and the latest daily build. Both give
the same error.
a...@stratford:~/gdal/gdal-1.6.3 47% gmake
(cd port; gmake)
gmake[1]: Entering directory `/nashome/alan/gdal/gdal-1.6.3/port'
Alans wrote:
I am trying to build gdal on SUSE LINUX Enterprise Server 10 and I get the
following error. I have tried 1.6.3 and the latest daily build. Both give
the same error.
a...@stratford:~/gdal/gdal-1.6.3 47% gmake
(cd port; gmake)
gmake[1]: Entering directory
Frank Warmerdam wrote:
This is very odd - I've never seen something quite like it.
One work around would likely be to configure GDAL --without-libtool. I
wonder if 1.6.3 got released with an unstable libtool version. Could you
try 1.6.2 on this system and see if that works?
Alans wrote:
Frank Warmerdam wrote:
This is very odd - I've never seen something quite like it.
One work around would likely be to configure GDAL --without-libtool. I
wonder if 1.6.3 got released with an unstable libtool version. Could you
try 1.6.2 on this system and see if
Hi Alan,
This doesn't fix you problem specifically, but may help.
We usually use the packages from the OpenSuse Geo repository, which has SLES
specific builds available. (We are using SLES for most Linux servers in our
organisation)
See:
Folks,
I have prepared a new OSGeo4W gdal-dev package capturing the state
of GDAL as of lunchtime today. This is a windows package as part of
OSGeo4W. To use it install OSGeo4W and in the advanced install add
the gdal-dev package. Then in the OSGeo4W command shell type gdaldev
to switch to
Folks,
I would note that large -wm values can be very counter productive when
used in combination with SKIP_NOSOURCE. The problem is that the larger
the chunk size, you run into the chance that a large window will intersect
a small amount of data and the whole window ends up being processed -
I'm having the same problem described in this posting to the mailing
list: http://lists.osgeo.org/pipermail/gdal-dev/2009-July/021247.html.
I've tried a variety of versions of gdal and libdap but I get the same
result each time. My OS is a fresh install of Centos 5.4 and my most
recent
Hi,
It appears that my calls to RasterIO are about 10 times slower on
Windows than Linux when reading from the same dataset. I wouldn't
think that there would be a noticeable difference. Has anyone else
seen this? Is it possible that the overviews aren't being used on
Windows? Is there anyway
13 matches
Mail list logo
