Re: [gdal-dev] Compiling GDAL with Visual Studio 2015

[Christopher McGeorge]

Thank you for your help, Even.  Yes, I tried cleaning before rebuilding and 
even re-downloading the original source code.

Thank you for your posting on AppVeyour.  To verify, you simply downloaded the 
following file:

release-1800-x64-gdal-mapserver-src.zip

unzipped, changed to the "gdal" folder, uncommented out the following line in 
"nmake.opt":

#WIN64=YES

and ran the following command:

nmake -f makefile.vc MSVC_VER=1900 WIN64=yes

Thank you,
Chris

-Original Message-
From: Even Rouault [mailto:even.roua...@spatialys.com] 
Sent: Friday, July 01, 2016 6:23 PM
To: Christopher McGeorge ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Compiling GDAL with Visual Studio 2015

Le samedi 02 juillet 2016 02:13:03, vous avez écrit :
> Hi, Even.  Thank you for your response.  Yes, I uncommented out this 
> line in the nmake.opt file, and I used the "WIN64=yes" nmake 
> command-line argument.
> 

And MSVC_VER=1900 ?
Make sure to clean before rebuilding if you change options

Here's a successful build on AppVeyour in case that helps:
https://ci.appveyor.com/project/rouault/gdal-coverage/build/1.0.5162/job/7np9al6m0uriphp1

> Thank you,
> Chris
> 
> -Original Message-
> From: Even Rouault [mailto:even.roua...@spatialys.com]
> Sent: Friday, July 01, 2016 6:10 PM
> To: gdal-dev@lists.osgeo.org
> Cc: Christopher McGeorge 
> Subject: Re: [gdal-dev] Compiling GDAL with Visual Studio 2015
> 
> Le samedi 02 juillet 2016 01:57:10, Christopher McGeorge a écrit :
> > Hi.  Has anyone been able to build 64-bit GDAL 2.1 using Visual 
> > Studio 2015? I keep getting the following errors that I have not 
> > been able to
> 
> > resolve:
> Did you define WIN64=YES in nmake.opt/nmake.local ?
> 
> > LINK : error LNK2001: unresolved external symbol 
> > OCTNewCoordinateTransformation
> > 
> > LINK : error LNK2001: unresolved external symbol GDALDitherRGB2PCT
> > 
> > LINK : error LNK2001: unresolved external symbol 
> > GDALComputeMedianCutPCT
> > 
> > LINK : error LNK2001: unresolved external symbol GDALReprojectImage
> > 
> > LINK : error LNK2001: unresolved external symbol GDALSimpleImageWarp
> > 
> > LINK : error LNK2001: unresolved external symbol OGRRegisterAll
> > 
> > LINK : error LNK2001: unresolved external symbol OGR_G_GetPointCount
> > 
> > LINK : error LNK2001: unresolved external symbol 
> > OPTGetProjectionMethods
> > 
> > LINK : error LNK2001: unresolved external symbol OSRValidate
> > 
> > gdal201.dll : fatal error LNK1120: 9 unresolved externals
> > 
> > 
> > 
> > Thank you,
> > 
> > Chris
> > 
> > 
> > 
> > ---
> > This email has been checked for viruses by Avast antivirus software.
> > https://www.avast.com/antivirus
> 
> --
> Spatialys - Geospatial professional services http://www.spatialys.com
> 
> 
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus

--
Spatialys - Geospatial professional services http://www.spatialys.com


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Compiling GDAL with Visual Studio 2015

[Even Rouault]

Le samedi 02 juillet 2016 02:13:03, vous avez écrit :
> Hi, Even.  Thank you for your response.  Yes, I uncommented out this line
> in the nmake.opt file, and I used the "WIN64=yes" nmake command-line
> argument.
> 

And MSVC_VER=1900 ?
Make sure to clean before rebuilding if you change options

Here's a successful build on AppVeyour in case that helps:
https://ci.appveyor.com/project/rouault/gdal-coverage/build/1.0.5162/job/7np9al6m0uriphp1

> Thank you,
> Chris
> 
> -Original Message-
> From: Even Rouault [mailto:even.roua...@spatialys.com]
> Sent: Friday, July 01, 2016 6:10 PM
> To: gdal-dev@lists.osgeo.org
> Cc: Christopher McGeorge 
> Subject: Re: [gdal-dev] Compiling GDAL with Visual Studio 2015
> 
> Le samedi 02 juillet 2016 01:57:10, Christopher McGeorge a écrit :
> > Hi.  Has anyone been able to build 64-bit GDAL 2.1 using Visual Studio
> > 2015? I keep getting the following errors that I have not been able to
> 
> > resolve:
> Did you define WIN64=YES in nmake.opt/nmake.local ?
> 
> > LINK : error LNK2001: unresolved external symbol
> > OCTNewCoordinateTransformation
> > 
> > LINK : error LNK2001: unresolved external symbol GDALDitherRGB2PCT
> > 
> > LINK : error LNK2001: unresolved external symbol
> > GDALComputeMedianCutPCT
> > 
> > LINK : error LNK2001: unresolved external symbol GDALReprojectImage
> > 
> > LINK : error LNK2001: unresolved external symbol GDALSimpleImageWarp
> > 
> > LINK : error LNK2001: unresolved external symbol OGRRegisterAll
> > 
> > LINK : error LNK2001: unresolved external symbol OGR_G_GetPointCount
> > 
> > LINK : error LNK2001: unresolved external symbol
> > OPTGetProjectionMethods
> > 
> > LINK : error LNK2001: unresolved external symbol OSRValidate
> > 
> > gdal201.dll : fatal error LNK1120: 9 unresolved externals
> > 
> > 
> > 
> > Thank you,
> > 
> > Chris
> > 
> > 
> > 
> > ---
> > This email has been checked for viruses by Avast antivirus software.
> > https://www.avast.com/antivirus
> 
> --
> Spatialys - Geospatial professional services http://www.spatialys.com
> 
> 
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Compiling GDAL with Visual Studio 2015

[Christopher McGeorge]

Hi, Even.  Thank you for your response.  Yes, I uncommented out this line in 
the nmake.opt file, and I used the "WIN64=yes" nmake command-line argument.

Thank you,
Chris

-Original Message-
From: Even Rouault [mailto:even.roua...@spatialys.com] 
Sent: Friday, July 01, 2016 6:10 PM
To: gdal-dev@lists.osgeo.org
Cc: Christopher McGeorge 
Subject: Re: [gdal-dev] Compiling GDAL with Visual Studio 2015

Le samedi 02 juillet 2016 01:57:10, Christopher McGeorge a écrit :
> Hi.  Has anyone been able to build 64-bit GDAL 2.1 using Visual Studio 
> 2015? I keep getting the following errors that I have not been able to
> resolve:

Did you define WIN64=YES in nmake.opt/nmake.local ?
> 
> 
> 
> LINK : error LNK2001: unresolved external symbol 
> OCTNewCoordinateTransformation
> 
> LINK : error LNK2001: unresolved external symbol GDALDitherRGB2PCT
> 
> LINK : error LNK2001: unresolved external symbol 
> GDALComputeMedianCutPCT
> 
> LINK : error LNK2001: unresolved external symbol GDALReprojectImage
> 
> LINK : error LNK2001: unresolved external symbol GDALSimpleImageWarp
> 
> LINK : error LNK2001: unresolved external symbol OGRRegisterAll
> 
> LINK : error LNK2001: unresolved external symbol OGR_G_GetPointCount
> 
> LINK : error LNK2001: unresolved external symbol 
> OPTGetProjectionMethods
> 
> LINK : error LNK2001: unresolved external symbol OSRValidate
> 
> gdal201.dll : fatal error LNK1120: 9 unresolved externals
> 
> 
> 
> Thank you,
> 
> Chris
> 
> 
> 
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus

--
Spatialys - Geospatial professional services http://www.spatialys.com


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Compiling GDAL with Visual Studio 2015

[Even Rouault]

Le samedi 02 juillet 2016 01:57:10, Christopher McGeorge a écrit :
> Hi.  Has anyone been able to build 64-bit GDAL 2.1 using Visual Studio
> 2015? I keep getting the following errors that I have not been able to
> resolve:

Did you define WIN64=YES in nmake.opt/nmake.local ?
> 
> 
> 
> LINK : error LNK2001: unresolved external symbol
> OCTNewCoordinateTransformation
> 
> LINK : error LNK2001: unresolved external symbol GDALDitherRGB2PCT
> 
> LINK : error LNK2001: unresolved external symbol GDALComputeMedianCutPCT
> 
> LINK : error LNK2001: unresolved external symbol GDALReprojectImage
> 
> LINK : error LNK2001: unresolved external symbol GDALSimpleImageWarp
> 
> LINK : error LNK2001: unresolved external symbol OGRRegisterAll
> 
> LINK : error LNK2001: unresolved external symbol OGR_G_GetPointCount
> 
> LINK : error LNK2001: unresolved external symbol OPTGetProjectionMethods
> 
> LINK : error LNK2001: unresolved external symbol OSRValidate
> 
> gdal201.dll : fatal error LNK1120: 9 unresolved externals
> 
> 
> 
> Thank you,
> 
> Chris
> 
> 
> 
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Compiling GDAL with Visual Studio 2015

[Christopher McGeorge]

Hi.  Has anyone been able to build 64-bit GDAL 2.1 using Visual Studio 2015?
I keep getting the following errors that I have not been able to resolve:

 

LINK : error LNK2001: unresolved external symbol
OCTNewCoordinateTransformation

LINK : error LNK2001: unresolved external symbol GDALDitherRGB2PCT

LINK : error LNK2001: unresolved external symbol GDALComputeMedianCutPCT

LINK : error LNK2001: unresolved external symbol GDALReprojectImage

LINK : error LNK2001: unresolved external symbol GDALSimpleImageWarp

LINK : error LNK2001: unresolved external symbol OGRRegisterAll

LINK : error LNK2001: unresolved external symbol OGR_G_GetPointCount

LINK : error LNK2001: unresolved external symbol OPTGetProjectionMethods

LINK : error LNK2001: unresolved external symbol OSRValidate

gdal201.dll : fatal error LNK1120: 9 unresolved externals

 

Thank you,

Chris



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] R: Problem using ogrlineref

[積丹尼 Dan Jacobson]

Well OK but the Debian guy closed all my bug reports instantly,
and on the man page you will need to give full examples, including input file 
content,
before any of this becomes understandable. Thanks.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdalbuildvrt 2.1.0 and off by 1 pixel display

[Even Rouault]

Le vendredi 01 juillet 2016 22:48:36, Jed Frechette a écrit :
> On 2016-07-01 1:51 PM, Even Rouault wrote:
> > If read by GDAL < 2.1, those VRT files will
> > exhibit possible one-off shift, since those older versions only read
> > values as integers. Is it your case ?
> 
> I see it in QGIS 2.14.3 (built against GDAL 2.0.2 and 2.1.0), QGIS
> 2.15.0 91c2d76 (GDAL 2.1.0), and ArcMap 10.1.
> 
> It seems like this has the potential to cause a lot of subtle issues in
> third party applications that, for various reasons, may be using
> different versions of the GDAL library. It also worries me that I'm
> seeing the offset in versions of QGIS (including the current weekly
> snapshot) that are reportedly built with GDAL 2.1.
> 
> > Could you share a way to reproduce the issue ?

I've pushed a fix in https://trac.osgeo.org/gdal/ticket/6568 

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdalbuildvrt 2.1.0 and off by 1 pixel display

[Even Rouault]

Le vendredi 01 juillet 2016 20:43:24, Jed Frechette a écrit :
> Starting with version 2.1.0 I've started to see display errors in both
> QGIS and ArcGIS for datasets built with gdalbuildvrt. In both cases, the
> vrt data ends up offset by 1 pixel relative to the source files. This
> offset is not consistent between applications or within the data set. My
> guess is that what I'm seeing are rounding errors as a result of
> Changeset 30648 [1] writing source and destination offsets and sizes as
> floats rather than integers.
> 
> Here is a snippet of a VRT generated by 2.0.0::
> 
> 
>slpc/test01.tif
>1
> BlockXSize="952" BlockYSize="8" />
>
>
>0
> 
> 
> And the equivalent snippet generated by 2.1.0::
> 
> 
>slpc/test01.tif
>1
> BlockXSize="952" BlockYSize="8" />
>
> ySize="1189.373" />
>0
> 
> 
> Both VRT files were generated in the same way::
> 
> gdalbuildvrt -tr 0.05 0.05 -tap slpc.vrt slpc/*tif
> 
> Note that the results are the same whether or not I use the -tr and -tap
> flags. Looking at other ComplexSources the DstRect offsets and sizes are
> always the values that are inconsistently rounded to integers with any
> of them potentially containing floats in the xml file. The VRT files
> were created on different systems with significantly different
> configurations so it is entirely possible that there is some local issue
> with my setup that is introducing this problem.
> 
> So I guess my first question is: Can anyone else confirm this issue? If
> so should it be considered a bug in GDAL or is up to other applications
> to adapt to this behavior?

Jed,

Yes GDAL 2.1 can produce floating point numbers, which can help to get sub-
pixel precision in some use cases. If read by GDAL < 2.1, those VRT files will 
exhibit possible one-off shift, since those older versions only read values as 
integers. Is it your case ?
Perhaps GDAL could be improved to avoid those issues by rounding to closest 
integer when numbers are very close like in your use case. Could you share a 
way to reproduce the issue ?

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] gdalbuildvrt 2.1.0 and off by 1 pixel display

[Jed Frechette]

Starting with version 2.1.0 I've started to see display errors in both
QGIS and ArcGIS for datasets built with gdalbuildvrt. In both cases, the
vrt data ends up offset by 1 pixel relative to the source files. This
offset is not consistent between applications or within the data set. My
guess is that what I'm seeing are rounding errors as a result of
Changeset 30648 [1] writing source and destination offsets and sizes as
floats rather than integers.

Here is a snippet of a VRT generated by 2.0.0::


  slpc/test01.tif
  1
  
  
  
  0


And the equivalent snippet generated by 2.1.0::


  slpc/test01.tif
  1
  
  
  
  0


Both VRT files were generated in the same way::

gdalbuildvrt -tr 0.05 0.05 -tap slpc.vrt slpc/*tif

Note that the results are the same whether or not I use the -tr and -tap 
flags. Looking at other ComplexSources the DstRect offsets and sizes are 
always the values that are inconsistently rounded to integers with any 
of them potentially containing floats in the xml file. The VRT files 
were created on different systems with significantly different 
configurations so it is entirely possible that there is some local issue 
with my setup that is introducing this problem.


So I guess my first question is: Can anyone else confirm this issue? If 
so should it be considered a bug in GDAL or is up to other applications 
to adapt to this behavior?


Thanks,

[1] https://trac.osgeo.org/gdal/changeset/30648
--
Jed Frechette
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Amplitude virtual bands for complex datasets ?

[Antonio Valentino]

Hi Bugbuster,

Il 01/07/2016 08:52, Bugbuster ha scritto:
> Hi Antonio,
> 
> I did try the test suite you provided. I tried to convert all VRT images to
> GTiff with the simple command :
> 
> 
> None of them gave any results.

please ensure to have gdal_PIXFUN.so in the GDAL_DRIVER_PATH:

env GDAL_DRIVER_PATH=../../.. gdal_translate -of GTiff pixfun_cmul_c.vrt
pixfun_cmul_c.vrt.tif

> In each function, I added a debug message when testing the number of source
> rasters :
> 
> I always get :
> 
> 
> If you have any ideas, I would be very grateful to you :-)
> Thanks
> Philippe


regards

-- 
Antonio Valentino
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Removing one of the two svn:keyword Id lines in all source files

[Kurt Schwehr]

See: https://trac.osgeo.org/gdal/ticket/6547

I propose to remove the $id line from the comments at the top of the file
for files that already have CPL_CVSID.  Having two lines means we have a
redundant copy of all this info, which is changing for every commit.

In addition, I propose to set the svn:keywords for these files to just be
Id.  Some have more and some have none.  e.g.

svn propset svn:keywords Id gdal_rpc.cpp
svn propset svn:keywords Id gdaltransformgeolocs.cpp
svn commit

https://trac.osgeo.org/gdal/changeset/34506

grep Id gdal_rpc.cpp gdaltransformgeolocs.cpp

gdal_rpc.cpp: * $Id: gdal_rpc.cpp 34506 2016-07-01 17:08:58Z goatbar $
gdal_rpc.cpp:CPL_CVSID("$Id: gdal_rpc.cpp 34506 2016-07-01 17:08:58Z
goatbar $");
gdaltransformgeolocs.cpp: * $Id: gdaltransformgeolocs.cpp 34506 2016-07-01
17:08:58Z goatbar $
gdaltransformgeolocs.cpp:CPL_CVSID("$Id: gdaltransformgeolocs.cpp 34506
2016-07-01 17:08:58Z goatbar $");

Then removing the redundant line, it becomes:

grep Id gdal_rpc.cpp gdaltransformgeolocs.cpp

gdal_rpc.cpp:CPL_CVSID("$Id: gdal_rpc.cpp 34506 2016-07-01 17:08:58Z
goatbar $");
gdaltransformgeolocs.cpp:CPL_CVSID("$Id: gdaltransformgeolocs.cpp 34506
2016-07-01 17:08:58Z goatbar $");

Why?  It's extra churn in diffs/patches and adds yet another line to check
for those of use using merge tools like meld a lot (which might just be me).

Anyone against this?  I'm proposing this just for head on trunk.

-kurt
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdal_calc.py IF ELSE Condition

[Gabriele N.]

Ciao Antonio.

Now everything looks perfect.

Thank you very much


Gabriele



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/gdal-calc-py-IF-ELSE-Condition-tp5274166p5274365.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] make install fails

[Kai Muehlbauer]

Hi Marco,

thanks for the reply.

Although I tried to dig up every related issue, I didn't find.

Am 01.07.2016 um 13:35 schrieb Marco Atzeri:

On 01/07/2016 13:20, Kai Muehlbauer wrote:

Hi Matthias,

I did experience the same issue. See

https://lists.osgeo.org/pipermail/gdal-dev/2016-July/044678.html

Although I did not find the root cause of this, I found that in my use
case, copying and unsetting CC and CXX environment variables did the
trick.

So what I did is:

export CF_CC=$CC
export CF_CXX=$CXX
unset CC CXX
./configure CC=$CF_CC \
CXX=$CF_CXX \
--prefix=$PREFIX
make

Hoping for more insight by gdal-devs.

Cheers,
Kai



same workaround "unset CC CXX"
is implemented for cygwin package build.

   https://lists.osgeo.org/pipermail/gdal-dev/2016-April/044171.html

and it looks this bug is present by long long time

   http://www.michael-joost.de/gdal_install.html


This is a annoying problem for quite some gdal users. With the four of 
us, who reported this problem here on the list, there is these on github:


https://github.com/LLNL/spack/issues/679
https://github.com/Homebrew/legacy-homebrew/issues/19845
https://github.com/lunar-linux/moonbase-other/pull/310

And all those unkown, who just use the workaround proposed Michael Joost.

I would really like to get some response on that from gdal-devs. (I'll 
not be nagging any more now).


Cheers,
Kai



Regards
Marco
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


--
Kai Muehlbauer
Meteorological Institute University of Bonn
Auf dem Huegel 20   | +49 228 739083
D-53121 Bonn| kai.muehlba...@uni-bonn.de
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] make install fails

[Marco Atzeri]

On 01/07/2016 13:20, Kai Muehlbauer wrote:

Hi Matthias,

I did experience the same issue. See

https://lists.osgeo.org/pipermail/gdal-dev/2016-July/044678.html

Although I did not find the root cause of this, I found that in my use
case, copying and unsetting CC and CXX environment variables did the trick.

So what I did is:

export CF_CC=$CC
export CF_CXX=$CXX
unset CC CXX
./configure CC=$CF_CC \
CXX=$CF_CXX \
--prefix=$PREFIX
make

Hoping for more insight by gdal-devs.

Cheers,
Kai



same workaround "unset CC CXX"
is implemented for cygwin package build.

  https://lists.osgeo.org/pipermail/gdal-dev/2016-April/044171.html

and it looks this bug is present by long long time

  http://www.michael-joost.de/gdal_install.html

Regards
Marco
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] make install fails

[Kai Muehlbauer]

Hi Matthias,

I did experience the same issue. See

https://lists.osgeo.org/pipermail/gdal-dev/2016-July/044678.html

Although I did not find the root cause of this, I found that in my use 
case, copying and unsetting CC and CXX environment variables did the trick.


So what I did is:

export CF_CC=$CC
export CF_CXX=$CXX
unset CC CXX
./configure CC=$CF_CC \
CXX=$CF_CXX \
--prefix=$PREFIX
make

Hoping for more insight by gdal-devs.

Cheers,
Kai

Am 03.03.2016 um 11:31 schrieb Matthias Kuhn:

Hi,

I am trying to compile and install gdal in docker (ubuntu 12.04)
container with python3 and in a custom prefix (/home/travis/deps),
clang-3.6 is used. configure and make run fine, however, make install fails:

/bin/bash -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions
-Wl,-Bsymbolic-functions -Wl,-z,relro
build/temp.linux-x86_64-3.2/extensions/osr_wrap.o -L../../.libs -L../../
-L/usr/src/gdal-2.0.2/lib -lgdal -o
build/lib.linux-x86_64-3.2/osgeo/_osr.cpython-32mu.so
/bin/bash: -d: invalid option
error: command '/bin/bash' failed with exit status 1

Any idea what could be the cause for this? I am grateful for any hints!

Thank you in advance,
Matthias
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev



--
Kai Muehlbauer
Meteorological Institute University of Bonn
Auf dem Huegel 20   | +49 228 739083
D-53121 Bonn| kai.muehlba...@uni-bonn.de
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL python bindings build error (gcc command replaced by bash)

[Kai Muehlbauer]

Hi James,

I did experience the same issue. See

https://lists.osgeo.org/pipermail/gdal-dev/2016-July/044678.html

Although I did not find the root cause of this, I found that in my use 
case, copying and unsetting CC and CXX environment variables did the trick.


So what I did is:

export CF_CC=$CC
export CF_CXX=$CXX
unset CC CXX
./configure CC=$CF_CC \
CXX=$CF_CXX \
--prefix=$PREFIX
make

Hoping for more insight by gdal-devs.

Cheers,
Kai


Am 25.05.2016 um 17:13 schrieb James Nunn:

Hi

I'm building gdal on linux (64bit ubuntu 16) with python bindings, and I'm
coming across a strange error right at the end of the python build steps
where exactly 4 commands which *should* be run with `x86_64-linux-gnu-gcc`
are instead run as `/bin/bash`.

Here are the last few lines of output before the error is encountered (look
for /bin/bash -pthread ... command after the python header warnings:

make[1]: Entering directory '/home/james/src/gdal/gdal/swig'
for dir in python ; do (cd $dir; make build) || exit; done
make[2]: Entering directory '/home/james/src/gdal/gdal/swig/python'
rm -f setup_vars.ini
echo 'GNM_ENABLED=no' >> setup_vars.ini
python setup.py build
running build
running build_py
creating build
creating build/lib.linux-x86_64-2.7
copying gdal.py -> build/lib.linux-x86_64-2.7
copying ogr.py -> build/lib.linux-x86_64-2.7
copying osr.py -> build/lib.linux-x86_64-2.7
copying gdalconst.py -> build/lib.linux-x86_64-2.7
copying gdalnumeric.py -> build/lib.linux-x86_64-2.7
creating build/lib.linux-x86_64-2.7/osgeo
copying osgeo/gnm.py -> build/lib.linux-x86_64-2.7/osgeo
copying osgeo/gdalnumeric.py -> build/lib.linux-x86_64-2.7/osgeo
copying osgeo/gdal_array.py -> build/lib.linux-x86_64-2.7/osgeo
copying osgeo/gdalconst.py -> build/lib.linux-x86_64-2.7/osgeo
copying osgeo/osr.py -> build/lib.linux-x86_64-2.7/osgeo
copying osgeo/__init__.py -> build/lib.linux-x86_64-2.7/osgeo
copying osgeo/gdal.py -> build/lib.linux-x86_64-2.7/osgeo
copying osgeo/ogr.py -> build/lib.linux-x86_64-2.7/osgeo
running build_ext
building 'osgeo._gdal' extension
creating build/temp.linux-x86_64-2.7
creating build/temp.linux-x86_64-2.7/extensions
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g
-fstack-protector -Wformat -Werror=format-security -fPIC -I../../port
-I../../gcore -I../../alg -I../../ogr/ -I../../ogr/ogrsf_frmts -I../../gnm
-I../../apps -I/usr/include/python2.7
-I/home/james/local/farmenv/local/lib/python2.7/site-packages/numpy/core/include
-I/home/james/src/gdal/gdal/include -c extensions/gdal_wrap.cpp -o
build/temp.linux-x86_64-2.7/extensions/gdal_wrap.o
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for
C/ObjC but not for C++
In file included from /usr/include/python2.7/Python.h:133:0,
  from extensions/gdal_wrap.cpp:155:
extensions/gdal_wrap.cpp: In function ‘PyObject*
_wrap_MajorObject_SetMetadata__SWIG_0(PyObject*, PyObject*)’:
/usr/include/python2.7/abstract.h:1354:62: warning: deprecated conversion
from string constant to ‘char*’ [-Wwrite-strings]
  #define PyMapping_Items(O) PyObject_CallMethod(O,"items",NULL)
   ^
extensions/gdal_wrap.cpp:9115:31: note: in expansion of macro
‘PyMapping_Items’
  PyObject *item_list = PyMapping_Items( obj1 );
^
/bin/bash -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions
-Wl,-Bsymbolic-functions -Wl,-z,relro -fno-strict-aliasing -DNDEBUG -g
-fwrapv -O2 -Wall -Wstrict-prototypes -Wdate-time -D_FORTIFY_SOURCE=2 -g
-fstack-protector -Wformat -Werror=format-security -Wl,-Bsymbolic-functions
-Wl,-z,relro -Wdate-time -D_FORTIFY_SOURCE=2 -g -fstack-protector -Wformat
-Werror=format-security build/temp.linux-x86_64-2.7/extensions/gdal_wrap.o
-L../../.libs -L../../ -L/home/james/src/gdal/gdal/lib -lgdal -o
build/lib.linux-x86_64-2.7/osgeo/_gdal.so
/bin/bash: -d: invalid option
error: command '/bin/bash' failed with exit status 1
GNUmakefile:74: recipe for target 'build' failed
make[2]: *** [build] Error 1
make[2]: Leaving directory '/home/james/src/gdal/gdal/swig/python'
GNUmakefile:30: recipe for target 'build' failed
make[1]: *** [build] Error 2
make[1]: Leaving directory '/home/james/src/gdal/gdal/swig'
GNUmakefile:104: recipe for target 'swig-modules' failed
make: *** [swig-modules] Error 2


If I manually re-run the failing commands replacing `/bin/bash` with
`x86_64-linux-gnu-gcc`, the entire build eventually succeeds.


Can anyone shed light on why the command is being replaced?


Regards

James



___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev



--
Kai Muehlbauer
Meteorological Institute University of Bonn
Auf dem Huegel 20   | +49 228 739083
D-53121 Bonn| kai.muehlba...@uni-bonn.de
___

[gdal-dev] GDAL/OGR 2.0.3 RC2 Available for Review

[Even Rouault]

I'm backing out RC1 to add a last minute fix for a regression introduced in 
2.0.1:
 * morphToESRI(): correctly compute standard_parallel_1 of Mercator(2SP) 
projection from scale factor of Mercator(1SP) (#6456, #4861)

Updated links:
   http://download.osgeo.org/gdal/2.0.3/gdal-2.0.3RC2.tar.xz
   http://download.osgeo.org/gdal/2.0.3/gdal-2.0.3RC2.tar.gz
   http://download.osgeo.org/gdal/2.0.3/gdal203RC2.zip
   http://download.osgeo.org/gdal/2.0.3/gdalautotest-2.0.3RC2.tar.gz
   http://download.osgeo.org/gdal/2.0.3/gdalautotest-2.0.3RC2.zip

Le vendredi 01 juillet 2016 11:16:21, Even Rouault a écrit :
> And now GDAL/OGR 2.0.3 release candidate. Please
> review and test.
> 
> Peek up an archive among the following ones (by ascending size):
> 
>   http://download.osgeo.org/gdal/2.0.3/gdal-2.0.3RC1.tar.xz
>   http://download.osgeo.org/gdal/2.0.3/gdal-2.0.3RC1.tar.gz
>   http://download.osgeo.org/gdal/2.0.3/gdal203RC1.zip
> 
> A snapshot of the gdalautotest suite is also available :
> 
>   http://download.osgeo.org/gdal/2.0.3/gdalautotest-2.0.3.tar.gz
>   http://download.osgeo.org/gdal/2.0.3/gdalautotest-2.0.3.zip
> 
> The NEWS file is here :
> 
>   http://trac.osgeo.org/gdal/wiki/Release/2.0.3-News
> 
> I'll call for a vote promoting it to final in the next days if no
> serious problems are reported before.
> 
> Best regards,
> 
> Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GDAL/OGR 2.0.3 RC1 Available for Review

[Even Rouault]

And now GDAL/OGR 2.0.3 release candidate. Please 
review and test.

Peek up an archive among the following ones (by ascending size):

  http://download.osgeo.org/gdal/2.0.3/gdal-2.0.3RC1.tar.xz
  http://download.osgeo.org/gdal/2.0.3/gdal-2.0.3RC1.tar.gz
  http://download.osgeo.org/gdal/2.0.3/gdal203RC1.zip

A snapshot of the gdalautotest suite is also available :

  http://download.osgeo.org/gdal/2.0.3/gdalautotest-2.0.3.tar.gz
  http://download.osgeo.org/gdal/2.0.3/gdalautotest-2.0.3.zip

The NEWS file is here :

  http://trac.osgeo.org/gdal/wiki/Release/2.0.3-News

I'll call for a vote promoting it to final in the next days if no 
serious problems are reported before.

Best regards,

Even
-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GDAL/OGR 1.11.5 RC1 Available for Review

[Even Rouault]

Hi,

As announced, I have prepared a GDAL/OGR 1.11.5 release candidate. Please 
review and test.

Peek up an archive among the following ones (by ascending size):

  http://download.osgeo.org/gdal/1.11.5/gdal-1.11.5RC1.tar.xz
  http://download.osgeo.org/gdal/1.11.5/gdal-1.11.5RC1.tar.gz
  http://download.osgeo.org/gdal/1.11.5/gdal1115RC1.zip

A snapshot of the gdalautotest suite is also available :

  http://download.osgeo.org/gdal/1.11.5/gdalautotest-1.11.5.tar.gz
  http://download.osgeo.org/gdal/1.11.5/gdalautotest-1.11.5.zip

The NEWS file is here :

  http://trac.osgeo.org/gdal/wiki/Release/1.11.5-News

I'll call for a vote promoting it to final in the next days if no 
serious problems are reported before.

2.0.3RC1 to follow, and 2.1.1RC1 as soon as I get confirmation that a yesterday 
fix is correct.

Best regards,

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] R: Problem using ogrlineref

[Dmitry Baryshnikov]

Hi Dan,

I see your tickets on debian bug tracker.
1. ogrlineref support all GDAL vector drivers with write capability
2. You didn't set -f (format) option, so default driver was set - ESRI 
shape file

3. I reproduce segmentation fault (will be fixed soon)
4. Current implementation have the only option to return distance along 
line for some geographic coordinates and coordinates for distance. So 
you need to loop every 500 meters to get what you want.
5. We tested using ogrlineref without any repers (reference point, 
milestones) and it works. You only need to add to OGRLayer three fields 
(beg type of REAL, end type of REAL and scale type of REAL).
6. KML is not good format as ogrlineref expect some attributes filled, 
but KML usually has the few attributes (NAME and Description). In that 
case ogrlineref cannot get some sensitive data from attributes.


Best regards,
Dmitry

01.07.2016 10:10, 積丹尼 Dan Jacobson пишет:

I am trying to use the ogrlineref command.
I can't even understand its man page.
Maybe it only works on shapefiles.
Maybe it only Seg Faults.

How can I get the locations of the kilometer markers given only this KML:


   zaokeng main road 中45市道
   
 1
 120.86817,24.17922,0.0 120.86816,24.17922,0.0...
   


Let's say put the output into a new KML file.

OK maybe I need these redundant starting and ending points too:

   Start
   
 120.86817,24.17922,0.0
   


   End
   
 120.86696,24.16733,0.0
   


Anyway the man page is just a mishmosh to me.

Maybe if you show me how to do it, then I can figure out what "reper"
points are. They certainly aren't English. Maybe I don't need "reper"
points. Maybe I am trying to produce "reper" point.
Nobody knows.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] R: Problem using ogrlineref

[積丹尼 Dan Jacobson]

I just have a single .
I want to put kilometer markers along it.
That is all I am trying to do.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] R: Problem using ogrlineref

[積丹尼 Dan Jacobson]

I am trying to use the ogrlineref command.
I can't even understand its man page.
Maybe it only works on shapefiles.
Maybe it only Seg Faults.

How can I get the locations of the kilometer markers given only this KML:


  zaokeng main road 中45市道
  
1
120.86817,24.17922,0.0 120.86816,24.17922,0.0...
  


Let's say put the output into a new KML file.

OK maybe I need these redundant starting and ending points too:

  Start
  
120.86817,24.17922,0.0
  


  End
  
120.86696,24.16733,0.0
  


Anyway the man page is just a mishmosh to me.

Maybe if you show me how to do it, then I can figure out what "reper"
points are. They certainly aren't English. Maybe I don't need "reper"
points. Maybe I am trying to produce "reper" point.
Nobody knows.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Amplitude virtual bands for complex datasets ?

[Bugbuster]

Hi Antonio,

I did try the test suite you provided. I tried to convert all VRT images to
GTiff with the simple command :


None of them gave any results.
In each function, I added a debug message when testing the number of source
rasters :

I always get :


If you have any ideas, I would be very grateful to you :-)
Thanks
Philippe



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/gdal-dev-Amplitude-virtual-bands-for-complex-datasets-tp5273713p5274296.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] building gdal with python and libtool

[Kai Muehlbauer]

Hi all,

I tried to reproduce this with a standard linux system. So I used my 
OpenSuse Leap42 Box.


Steps to reproduce:

1. Download gdal-2.1.0 tarball
2. extract to some folder
3. ./configure --prefix=/usr/local --with-python
4. make

This builds fine using libtool.

5. extract gdal tarball to another folder (just to be sure)
6. export CC=gcc
7. export CXX=g++
8. ./configure --prefix=/usr/local --with-python
9. make

This fails in swig/python with the error mentioned in the OP. See 
attached excerpt of the build log.


I haven't found anything related to this special problem yet. But it 
turns out, that something is happening in the combination of `configure` 
and `libtool` when CC and CXX are exported in the environment. It is 
actually working, if you add `--without-libtool` to the call to `configure`.


To come back to my OP, we are using this approach (exporting CC and CXX) 
to build different packages, but only experiencing this issue with gdal 
so far.


It would be very helpful, if gdal-devs could have a look into this.

Thanks again!

Cheers,
Kai




Am 27.06.2016 um 20:49 schrieb Kai Mühlbauer:

Hi all,

while trying to build gdal on linux (on CircleCi in a CentOS based
docker image using conda/conda-forge) like this:


export CC=gcc
export CXX=g++
export CFLAGS="${CFLAGS}"
export CXXFLAGS="${CXXFLAGS} -DBOOST_MATH_DISABLE_FLOAT128"
export LDFLAGS="${LDFLAGS}"
export LINKFLAGS="${LDFLAGS}"
export CFLAGS="${CFLAGS} -m${ARCH}"
export CXXFLAGS="${CXXFLAGS} -m${ARCH}"

export LDFLAGS="$LDFLAGS -L$PREFIX/lib"
export CPPFLAGS="$CPPFLAGS -I$PREFIX/include"

./configure --prefix=$PREFIX \
 --with-hdf4=$PREFIX \
 --with-hdf5=$PREFIX \
 --with-xerces=$PREFIX \
 --with-netcdf=$PREFIX \
 --with-geos=$PREFIX/bin/geos-config \
 --with-kea=$PREFIX/bin/kea-config \
 --with-static-proj4=$PREFIX \
 --with-libz=$PREFIX \
 --with-png=$PREFIX \
 --with-jpeg=$PREFIX \
 --with-libjson-c=$PREFIX \
 --with-expat=$PREFIX \
 --with-freexl=$PREFIX \
 --with-libtiff=$PREFIX \
 --with-xml2=$PREFIX \
 --with-openjpeg=$PREFIX \
 --with-spatialite=$PREFIX \
 --with-pg=$PREFIX/bin/pg_config \
 --with-sqlite3=$PREFIX \
 --with-curl \
 --with-python \
 --disable-rpath

make
make install
---

we are experiencing the same issue like posted here:

http://www.michael-joost.de/gdal_install.html

Everything works OK, until the build descends into the swig/python
subdir, then the two compile commands work using libtool. But when it
comes to linking, we get this error:

/bin/bash -pthread -shared -L/home/sam/miniconda3/envs/_build/lib
-Wl,-rpath=/home/sam/miniconda3/envs/_build/lib,--no-as-needed
-L/home/sam/miniconda3/envs/_build/lib
-L/home/sam/miniconda3/envs/_build/lib -m64 -Wall
-Wdeclaration-after-statement -Wextra -Winit-self -Wunused-parameter
-Wmissing-prototypes -Wmissing-declarations -Wformat
-Werror=format-security -Wno-format-nonliteral -Wlogical-op -Wshadow
-Werror=vla -Wdeclaration-after-statement -DOGR_ENABLED
-I/home/sam/miniconda3/envs/_build/include
-I/home/sam/miniconda3/conda-bld/work/gdal-2.1.0/port
-I/home/sam/miniconda3/envs/_build/include
-I/home/sam/miniconda3/envs/_build/include
-I/home/sam/miniconda3/envs/_build
-I/home/sam/miniconda3/envs/_build/include
-I/home/sam/miniconda3/envs/_build/include
-I/home/sam/miniconda3/envs/_build
-I/home/sam/miniconda3/envs/_build/include
-I/home/sam/miniconda3/envs/_build
-I/home/sam/miniconda3/envs/_build/include -DGDAL_COMPILATION
build/temp.linux-x86_64-3.4/extensions/gdal_wrap.o -L../../.libs
-L../../ -L/home/sam/miniconda3/envs/_build/lib
-L/home/sam/miniconda3/conda-bld/work/gdal-2.1.0/lib -lpython3.4m -lgdal
-o build/lib.linux-x86_64-3.4/osgeo/_gdal.cpython-34m.so
/bin/bash: -d: invalid option
error: command '/bin/bash' failed with exit status 1
make[2]: *** [build] Error 1
make[2]: Leaving directory
`/home/sam/miniconda3/conda-bld/work/gdal-2.1.0/swig/python'
make[1]: *** [build] Error 2
make[1]: Leaving directory
`/home/sam/miniconda3/conda-bld/work/gdal-2.1.0/swig'

Using internet search I found that it could be related to wrongly set
environment variables. But I can't find any problems so far. Using
configure with --without-libtool leads to stable build without errors.

Although we can build gdal this way, we like to find the root cause of
this libtool-problem. Any hints appreciated!

Cheers,
Kai
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


--
Kai Muehlbauer
Meteorological Institute University of Bonn
Auf dem Huegel 20   | +49 228 739083
D-53121 Bonn|