Re: gdal 1.9.1 (Was Re: graphics/gdal 1.9.0 does not build on CURRENT)
Le 28.05.2012 18:37, Rainer Hurling a écrit : On 28.05.2012 18:18 (UTC+1), Sunpoet Po-Chuan Hsieh wrote: Hi, Here's just a status update. I'm working on GDAL 1.9.1 update. That's nice to hear. I agree. I plan to move perl/php/python/ruby bindings to separate ports. It also removes dirty python hacks from the master port. And the (slave) ports we would have to install additionally, if we want the bindings? Sounds reasonable. You consider gdal like a metaport ? Needs also the java binding. What about the R-gdal and gdal-grass ports ? BTW, it seems swig 1.3.40 is enough for GDAL 1.9.1. So most people would only need 1.3.40 and not a parallel 2.0.x installation. I can build ruby-gdal successfully with swig 1.3.40 and ruby 1.9. But I haven't tested if the generated shared libraries are OK. Good luck also with MDB (java) and the shared libraries. I will try to port some drivers : - libgta http://gta.nongnu.org/gtatool.html - ogdi http://ogdi.sourceforge.net/ - FileGDBAPI Esri http://resources.arcgis.com/content/geodatabases/10.0/file-gdb-api (I don't know about license...) - RASDAMAN http://rasdaman.eecs.jacobs-university.de/trac/rasdaman/wiki/Download And also, what do you think about the recurring question about unixODBC and libiodbc ? Thanks for your works. Loïc. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: gdal 1.9.1 (Was Re: graphics/gdal 1.9.0 does not build on CURRENT)
Le 27.05.2012 09:17, Rainer Hurling a écrit :
On 26.05.2012 18:41 (UTC+1), Rainer Hurling wrote:
On 26.05.2012 17:49 (UTC+2), coder.tuxfamily wrote:
Le 25.05.2012 22:49, Rainer Hurling a écrit :
On 25.05.2012 21:51 (UTC+1), coder.tuxfamily wrote:
Can you try to build the new port of gdal ?
I have the same problem with swig for php...
Thanks for the update. It builds and installs fine here on two boxes
with 10.0-CURRENT (amd64).
One issue which should be thought about before updating gdal in the
ports:
Does gdal-1.9.1 really needs swig 2.0? It seems so for at least libkml?
The problem is, that in your Makefile swig 2.0 conflicts with an
installed swig 1.3.40, which is needed for example by graphics/geos,
graphics/graphviz, math/saga, science/py-scipy and some others.
Affected ports can be found for example with
find /usr/ports -name Makefile -depth 3 -exec grep -l -e swig13 {} \;
I personally would prefer the newer swig 2.0 version (even for most
other ports). Do you think it is necessary to forbid a parallel swig
1.3.40 installation in your port? I read somewhere that both swig ports
can coexist in principle, only some docs share the same places (which
should be changed, of course).
Maybe you're right. I've see on trac.osgeo.org that it uses swig-1.3.40.
I will try without specify version of swig.
I saw in the news on http://www.swig.org/, that swig 2.0.6 is out with
many bug fixes and enhancements for templates and target languages like
php and python. Perhaps swig 2.0.6 is ready now for gdal?
I made a patch to update from swig 2.0.4 to 2.0.6. Could you please try
if at least some of the observed problems will disappear?
If this helps we should create a PR and ask the maintainer for an update.
I just checked, that swig 1.3.40 and 2.0.4 should be able to coexist at
the same time. At least they do not share any filenames.
The patch works but don't solve gdal problems. I think i've found were
it's wrong.
For Ruby/Swig :
See the page on GDAL : http://trac.osgeo.org/gdal/wiki/GdalOgrInRuby
SWIG 2 is required to build the Ruby bindings against Ruby 1.9.2. (SWIG
1.3.40 is fine for Ruby 1.8.7)
When i try to compile, i've two errors :
ogr_wrap.o: relocation R_X86_64_32 against `a local symbol' can not be
used when making a shared object; recompile with -fPIC
ogr_wrap.o: relocation R_X86_64_32 against `a local symbol' can not be
used when making a shared object; recompile with -fPIC
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: gdal 1.9.1 (Was Re: graphics/gdal 1.9.0 does not build on CURRENT)
Le 28.05.2012 08:59, coder.tuxfamily a écrit :
Le 27.05.2012 09:17, Rainer Hurling a écrit :
On 26.05.2012 18:41 (UTC+1), Rainer Hurling wrote:
On 26.05.2012 17:49 (UTC+2), coder.tuxfamily wrote:
Le 25.05.2012 22:49, Rainer Hurling a écrit :
On 25.05.2012 21:51 (UTC+1), coder.tuxfamily wrote:
Can you try to build the new port of gdal ?
I have the same problem with swig for php...
Thanks for the update. It builds and installs fine here on two boxes
with 10.0-CURRENT (amd64).
One issue which should be thought about before updating gdal in the
ports:
Does gdal-1.9.1 really needs swig 2.0? It seems so for at least
libkml?
The problem is, that in your Makefile swig 2.0 conflicts with an
installed swig 1.3.40, which is needed for example by graphics/geos,
graphics/graphviz, math/saga, science/py-scipy and some others.
Affected ports can be found for example with
find /usr/ports -name Makefile -depth 3 -exec grep -l -e swig13
{} \;
I personally would prefer the newer swig 2.0 version (even for most
other ports). Do you think it is necessary to forbid a parallel swig
1.3.40 installation in your port? I read somewhere that both swig
ports
can coexist in principle, only some docs share the same places (which
should be changed, of course).
Maybe you're right. I've see on trac.osgeo.org that it uses
swig-1.3.40.
I will try without specify version of swig.
I saw in the news on http://www.swig.org/, that swig 2.0.6 is out with
many bug fixes and enhancements for templates and target languages like
php and python. Perhaps swig 2.0.6 is ready now for gdal?
I made a patch to update from swig 2.0.4 to 2.0.6. Could you please try
if at least some of the observed problems will disappear?
If this helps we should create a PR and ask the maintainer for an update.
I just checked, that swig 1.3.40 and 2.0.4 should be able to coexist at
the same time. At least they do not share any filenames.
The patch works but don't solve gdal problems. I think i've found were
it's wrong.
For Ruby/Swig :
See the page on GDAL : http://trac.osgeo.org/gdal/wiki/GdalOgrInRuby
SWIG 2 is required to build the Ruby bindings against Ruby 1.9.2. (SWIG
1.3.40 is fine for Ruby 1.8.7)
When i try to compile, i've two errors :
ogr_wrap.o: relocation R_X86_64_32 against `a local symbol' can not be
used when making a shared object; recompile with -fPIC
ogr_wrap.o: relocation R_X86_64_32 against `a local symbol' can not be
used when making a shared object; recompile with -fPIC
For MDB driver (and for java port) it's needed some java stuff, but i
don't use java and so don't understand what to do
(http://trac.osgeo.org/gdal/wiki/GdalOgrInJavaBuildInstructionsUnix)
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: gdal 1.9.1 (Was Re: graphics/gdal 1.9.0 does not build on CURRENT)
On 28.05.2012 10:01 (UTC+1), coder.tuxfamily wrote:
Le 28.05.2012 08:59, coder.tuxfamily a écrit :
Le 27.05.2012 09:17, Rainer Hurling a écrit :
On 26.05.2012 18:41 (UTC+1), Rainer Hurling wrote:
On 26.05.2012 17:49 (UTC+2), coder.tuxfamily wrote:
Le 25.05.2012 22:49, Rainer Hurling a écrit :
On 25.05.2012 21:51 (UTC+1), coder.tuxfamily wrote:
Can you try to build the new port of gdal ?
I have the same problem with swig for php...
Thanks for the update. It builds and installs fine here on two boxes
with 10.0-CURRENT (amd64).
One issue which should be thought about before updating gdal in the
ports:
Does gdal-1.9.1 really needs swig 2.0? It seems so for at least
libkml?
The problem is, that in your Makefile swig 2.0 conflicts with an
installed swig 1.3.40, which is needed for example by graphics/geos,
graphics/graphviz, math/saga, science/py-scipy and some others.
Affected ports can be found for example with
find /usr/ports -name Makefile -depth 3 -exec grep -l -e swig13
{} \;
I personally would prefer the newer swig 2.0 version (even for most
other ports). Do you think it is necessary to forbid a parallel swig
1.3.40 installation in your port? I read somewhere that both swig
ports
can coexist in principle, only some docs share the same places (which
should be changed, of course).
Maybe you're right. I've see on trac.osgeo.org that it uses
swig-1.3.40.
I will try without specify version of swig.
I saw in the news on http://www.swig.org/, that swig 2.0.6 is out with
many bug fixes and enhancements for templates and target languages like
php and python. Perhaps swig 2.0.6 is ready now for gdal?
I made a patch to update from swig 2.0.4 to 2.0.6. Could you please try
if at least some of the observed problems will disappear?
If this helps we should create a PR and ask the maintainer for an
update.
I just checked, that swig 1.3.40 and 2.0.4 should be able to coexist at
the same time. At least they do not share any filenames.
The patch works but don't solve gdal problems. I think i've found were
it's wrong.
For Ruby/Swig :
See the page on GDAL : http://trac.osgeo.org/gdal/wiki/GdalOgrInRuby
SWIG 2 is required to build the Ruby bindings against Ruby 1.9.2. (SWIG
1.3.40 is fine for Ruby 1.8.7)
When i try to compile, i've two errors :
ogr_wrap.o: relocation R_X86_64_32 against `a local symbol' can not be
used when making a shared object; recompile with -fPIC
ogr_wrap.o: relocation R_X86_64_32 against `a local symbol' can not be
used when making a shared object; recompile with -fPIC
For MDB driver (and for java port) it's needed some java stuff, but i
don't use java and so don't understand what to do
(http://trac.osgeo.org/gdal/wiki/GdalOgrInJavaBuildInstructionsUnix)
While gdal-1.9.1 with option 'MDB' enabled compiles fine, I have another
failure with option 'Ruby bindings' enabled (both build with swig-2.0.6):
gmake[1]: Leaving directory `/usr/ports/graphics/gdal/work/gdal-1.9.1/apps'
(cd swig; gmake build)
gmake[1]: Entering directory `/usr/ports/graphics/gdal/work/gdal-1.9.1/swig'
for dir in ruby ; do (cd $dir; gmake build) || exit; done
gmake[2]: Entering directory
`/usr/ports/graphics/gdal/work/gdal-1.9.1/swig/ruby'
swig -Wall -I../include -I../include/ruby -I../include/ruby/docs
-autorename -prefix gdal:: -I/usr/ports/graphics/gdal/work/gdal-1.9.1
-c++ -ruby -o gdal_wrap.cpp ../include/gdal.i
swig: not found
gmake[2]: *** [gdal_wrap.cpp] Fehler 127
gmake[2]: Leaving directory
`/usr/ports/graphics/gdal/work/gdal-1.9.1/swig/ruby'
gmake[1]: *** [build] Fehler 2
gmake[1]: Leaving directory `/usr/ports/graphics/gdal/work/gdal-1.9.1/swig'
gmake: *** [swig-modules] Fehler 2
*** [do-build] Error code 1
Stop in /usr/ports/graphics/gdal.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: gdal 1.9.1 (Was Re: graphics/gdal 1.9.0 does not build on CURRENT)
Le 28.05.2012 14:37, Rainer Hurling a écrit :
On 28.05.2012 10:01 (UTC+1), coder.tuxfamily wrote:
Le 28.05.2012 08:59, coder.tuxfamily a écrit :
Le 27.05.2012 09:17, Rainer Hurling a écrit :
On 26.05.2012 18:41 (UTC+1), Rainer Hurling wrote:
On 26.05.2012 17:49 (UTC+2), coder.tuxfamily wrote:
Le 25.05.2012 22:49, Rainer Hurling a écrit :
On 25.05.2012 21:51 (UTC+1), coder.tuxfamily wrote:
Can you try to build the new port of gdal ?
I have the same problem with swig for php...
Thanks for the update. It builds and installs fine here on two boxes
with 10.0-CURRENT (amd64).
One issue which should be thought about before updating gdal in the
ports:
Does gdal-1.9.1 really needs swig 2.0? It seems so for at least
libkml?
The problem is, that in your Makefile swig 2.0 conflicts with an
installed swig 1.3.40, which is needed for example by graphics/geos,
graphics/graphviz, math/saga, science/py-scipy and some others.
Affected ports can be found for example with
find /usr/ports -name Makefile -depth 3 -exec grep -l -e swig13
{} \;
I personally would prefer the newer swig 2.0 version (even for most
other ports). Do you think it is necessary to forbid a parallel swig
1.3.40 installation in your port? I read somewhere that both swig
ports
can coexist in principle, only some docs share the same places
(which
should be changed, of course).
Maybe you're right. I've see on trac.osgeo.org that it uses
swig-1.3.40.
I will try without specify version of swig.
I saw in the news on http://www.swig.org/, that swig 2.0.6 is out with
many bug fixes and enhancements for templates and target languages
like
php and python. Perhaps swig 2.0.6 is ready now for gdal?
I made a patch to update from swig 2.0.4 to 2.0.6. Could you please try
if at least some of the observed problems will disappear?
If this helps we should create a PR and ask the maintainer for an
update.
I just checked, that swig 1.3.40 and 2.0.4 should be able to
coexist at
the same time. At least they do not share any filenames.
The patch works but don't solve gdal problems. I think i've found were
it's wrong.
For Ruby/Swig :
See the page on GDAL : http://trac.osgeo.org/gdal/wiki/GdalOgrInRuby
SWIG 2 is required to build the Ruby bindings against Ruby 1.9.2. (SWIG
1.3.40 is fine for Ruby 1.8.7)
When i try to compile, i've two errors :
ogr_wrap.o: relocation R_X86_64_32 against `a local symbol' can not be
used when making a shared object; recompile with -fPIC
ogr_wrap.o: relocation R_X86_64_32 against `a local symbol' can not be
used when making a shared object; recompile with -fPIC
For MDB driver (and for java port) it's needed some java stuff, but i
don't use java and so don't understand what to do
(http://trac.osgeo.org/gdal/wiki/GdalOgrInJavaBuildInstructionsUnix)
While gdal-1.9.1 with option 'MDB' enabled compiles fine, I have another
failure with option 'Ruby bindings' enabled (both build with swig-2.0.6):
Compile but don't work (need libjvm.so)
gmake[1]: Leaving directory `/usr/ports/graphics/gdal/work/gdal-1.9.1/apps'
(cd swig; gmake build)
gmake[1]: Entering directory
`/usr/ports/graphics/gdal/work/gdal-1.9.1/swig'
for dir in ruby ; do (cd $dir; gmake build) || exit; done
gmake[2]: Entering directory
`/usr/ports/graphics/gdal/work/gdal-1.9.1/swig/ruby'
swig -Wall -I../include -I../include/ruby -I../include/ruby/docs
-autorename -prefix gdal:: -I/usr/ports/graphics/gdal/work/gdal-1.9.1
-c++ -ruby -o gdal_wrap.cpp ../include/gdal.i
swig: not found
gmake[2]: *** [gdal_wrap.cpp] Fehler 127
gmake[2]: Leaving directory
`/usr/ports/graphics/gdal/work/gdal-1.9.1/swig/ruby'
gmake[1]: *** [build] Fehler 2
gmake[1]: Leaving directory `/usr/ports/graphics/gdal/work/gdal-1.9.1/swig'
gmake: *** [swig-modules] Fehler 2
*** [do-build] Error code 1
Stop in /usr/ports/graphics/gdal.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: gdal 1.9.1 (Was Re: graphics/gdal 1.9.0 does not build on CURRENT)
Hi, Here's just a status update. I'm working on GDAL 1.9.1 update. I plan to move perl/php/python/ruby bindings to separate ports. It also removes dirty python hacks from the master port. BTW, it seems swig 1.3.40 is enough for GDAL 1.9.1. I can build ruby-gdal successfully with swig 1.3.40 and ruby 1.9. But I haven't tested if the generated shared libraries are OK. Regards, sunpoet ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: gdal 1.9.1 (Was Re: graphics/gdal 1.9.0 does not build on CURRENT)
On 28.05.2012 18:18 (UTC+1), Sunpoet Po-Chuan Hsieh wrote: Hi, Here's just a status update. I'm working on GDAL 1.9.1 update. That's nice to hear. I plan to move perl/php/python/ruby bindings to separate ports. It also removes dirty python hacks from the master port. And the (slave) ports we would have to install additionally, if we want the bindings? Sounds reasonable. BTW, it seems swig 1.3.40 is enough for GDAL 1.9.1. So most people would only need 1.3.40 and not a parallel 2.0.x installation. I can build ruby-gdal successfully with swig 1.3.40 and ruby 1.9. But I haven't tested if the generated shared libraries are OK. Good luck also with MDB (java) and the shared libraries. Regards, sunpoet Thanks for the info and the work, Rainer ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: gdal 1.9.1 (Was Re: graphics/gdal 1.9.0 does not build on CURRENT)
Le 25.05.2012 22:49, Rainer Hurling a écrit :
On 25.05.2012 21:51 (UTC+1), coder.tuxfamily wrote:
Can you try to build the new port of gdal ?
I have the same problem with swig for php...
Thanks for the update. It builds and installs fine here on two boxes
with 10.0-CURRENT (amd64).
One issue which should be thought about before updating gdal in the ports:
Does gdal-1.9.1 really needs swig 2.0? It seems so for at least libkml?
The problem is, that in your Makefile swig 2.0 conflicts with an
installed swig 1.3.40, which is needed for example by graphics/geos,
graphics/graphviz, math/saga, science/py-scipy and some others.
Affected ports can be found for example with
find /usr/ports -name Makefile -depth 3 -exec grep -l -e swig13 {} \;
I personally would prefer the newer swig 2.0 version (even for most
other ports). Do you think it is necessary to forbid a parallel swig
1.3.40 installation in your port? I read somewhere that both swig ports
can coexist in principle, only some docs share the same places (which
should be changed, of course).
Maybe you're right. I've see on trac.osgeo.org that it uses swig-1.3.40.
I will try without specify version of swig.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: gdal 1.9.1 (Was Re: graphics/gdal 1.9.0 does not build on CURRENT)
On 26.05.2012 17:49 (UTC+2), coder.tuxfamily wrote:
Le 25.05.2012 22:49, Rainer Hurling a écrit :
On 25.05.2012 21:51 (UTC+1), coder.tuxfamily wrote:
Can you try to build the new port of gdal ?
I have the same problem with swig for php...
Thanks for the update. It builds and installs fine here on two boxes
with 10.0-CURRENT (amd64).
One issue which should be thought about before updating gdal in the
ports:
Does gdal-1.9.1 really needs swig 2.0? It seems so for at least libkml?
The problem is, that in your Makefile swig 2.0 conflicts with an
installed swig 1.3.40, which is needed for example by graphics/geos,
graphics/graphviz, math/saga, science/py-scipy and some others.
Affected ports can be found for example with
find /usr/ports -name Makefile -depth 3 -exec grep -l -e swig13 {} \;
I personally would prefer the newer swig 2.0 version (even for most
other ports). Do you think it is necessary to forbid a parallel swig
1.3.40 installation in your port? I read somewhere that both swig ports
can coexist in principle, only some docs share the same places (which
should be changed, of course).
Maybe you're right. I've see on trac.osgeo.org that it uses swig-1.3.40.
I will try without specify version of swig.
I saw in the news on http://www.swig.org/, that swig 2.0.6 is out with
many bug fixes and enhancements for templates and target languages like
php and python. Perhaps swig 2.0.6 is ready now for gdal?
I just checked, that swig 1.3.40 and 2.0.4 should be able to coexist at
the same time. At least they do not share any filenames.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: gdal 1.9.1 (Was Re: graphics/gdal 1.9.0 does not build on CURRENT)
Le 26.05.2012 18:41, Rainer Hurling a écrit :
On 26.05.2012 17:49 (UTC+2), coder.tuxfamily wrote:
Le 25.05.2012 22:49, Rainer Hurling a écrit :
On 25.05.2012 21:51 (UTC+1), coder.tuxfamily wrote:
Can you try to build the new port of gdal ?
I have the same problem with swig for php...
Thanks for the update. It builds and installs fine here on two boxes
with 10.0-CURRENT (amd64).
One issue which should be thought about before updating gdal in the
ports:
Does gdal-1.9.1 really needs swig 2.0? It seems so for at least libkml?
The problem is, that in your Makefile swig 2.0 conflicts with an
installed swig 1.3.40, which is needed for example by graphics/geos,
graphics/graphviz, math/saga, science/py-scipy and some others.
Affected ports can be found for example with
find /usr/ports -name Makefile -depth 3 -exec grep -l -e swig13 {} \;
I personally would prefer the newer swig 2.0 version (even for most
other ports). Do you think it is necessary to forbid a parallel swig
1.3.40 installation in your port? I read somewhere that both swig ports
can coexist in principle, only some docs share the same places (which
should be changed, of course).
Maybe you're right. I've see on trac.osgeo.org that it uses swig-1.3.40.
I will try without specify version of swig.
I saw in the news on http://www.swig.org/, that swig 2.0.6 is out with
many bug fixes and enhancements for templates and target languages like
php and python. Perhaps swig 2.0.6 is ready now for gdal?
I just checked, that swig 1.3.40 and 2.0.4 should be able to coexist at
the same time. At least they do not share any filenames.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Ruby option seems have also a problem with SWIG.
PGSQL conflict with ssl.
I need to add condition between podofo and poppler.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: graphics/gdal 1.9.0 does not build on CURRENT
On 23.05.2012 18:37 (UTC+1), Rainer Hurling wrote:
On 23.05.2012 18:22 (UTC+1), coder.tuxfamily wrote:
OK, I think I get it. This failure does not happen, if swig is not
installed. Then it builds and installs fine.
I tried to install gdal-1.9.0 on another 10.0-CURRENT box and it fails
completely. On that box I was not able to build gdal even without swig
or with swig 2.0 installed.
After that I tried on a 10.0-CURRENT Tinderbox with a totally unmodified
gdal-1.9.0 (even without the ${CPPFLAGS} patch). It builds just fine, no
problems at all!
So it must have to do with some special configurations and/or installed
packages.
The only clue I have at this time is, that
extensions/gdal_wrap.cpp:6845: complains about 'VSIFTruncateL', which
was not declared in this scope.
Do you have any idea what is going wrong with swig here?
OK. Maybe inclue the swig dependancy into the Makefile.
I just tested three cases:
(1) No swig installed - gdal 1.9.0 builds and installs fine
(2) swig 1.3.40 installed - the build breaks, see older mails
(3) swig 2.0.4 installed - gdal 1.9.0 builds and installs fine
So we only have to take care that swig 1.3.40 is not installed.
With swig installed, the pkg-plist of gdal is incomplete, 'make
deinstall' shows
pkg_delete: unable to completely remove directory '/usr/local/share/gdal'
pkg_delete: unable to completely remove directory
'/usr/local/lib/python2.7/site-packages/GDAL-1.9.0-py2.7-freebsd-10.0-CURRENT-amd64.egg/osgeo'
pkg_delete: unable to completely remove directory
'/usr/local/lib/python2.7/site-packages/GDAL-1.9.0-py2.7-freebsd-10.0-CURRENT-amd64.egg'
pkg_delete: couldn't entirely delete package `gdal-1.9.0'
(perhaps the packing list is incorrectly specified?)
I try to port gdal 1.9.1
That would be nice!
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
gdal 1.9.1 (Was Re: graphics/gdal 1.9.0 does not build on CURRENT)
Can you try to build the new port of gdal ?
I have the same problem with swig for php...
Le 25.05.2012 10:29, Rainer Hurling a écrit :
On 23.05.2012 18:37 (UTC+1), Rainer Hurling wrote:
On 23.05.2012 18:22 (UTC+1), coder.tuxfamily wrote:
OK, I think I get it. This failure does not happen, if swig is not
installed. Then it builds and installs fine.
I tried to install gdal-1.9.0 on another 10.0-CURRENT box and it fails
completely. On that box I was not able to build gdal even without swig
or with swig 2.0 installed.
After that I tried on a 10.0-CURRENT Tinderbox with a totally unmodified
gdal-1.9.0 (even without the ${CPPFLAGS} patch). It builds just fine, no
problems at all!
So it must have to do with some special configurations and/or installed
packages.
The only clue I have at this time is, that
extensions/gdal_wrap.cpp:6845: complains about 'VSIFTruncateL', which
was not declared in this scope.
Do you have any idea what is going wrong with swig here?
OK. Maybe inclue the swig dependancy into the Makefile.
I just tested three cases:
(1) No swig installed - gdal 1.9.0 builds and installs fine
(2) swig 1.3.40 installed - the build breaks, see older mails
(3) swig 2.0.4 installed - gdal 1.9.0 builds and installs fine
So we only have to take care that swig 1.3.40 is not installed.
With swig installed, the pkg-plist of gdal is incomplete, 'make
deinstall' shows
pkg_delete: unable to completely remove directory '/usr/local/share/gdal'
pkg_delete: unable to completely remove directory
'/usr/local/lib/python2.7/site-packages/GDAL-1.9.0-py2.7-freebsd-10.0-CURRENT-amd64.egg/osgeo'
pkg_delete: unable to completely remove directory
'/usr/local/lib/python2.7/site-packages/GDAL-1.9.0-py2.7-freebsd-10.0-CURRENT-amd64.egg'
pkg_delete: couldn't entirely delete package `gdal-1.9.0'
(perhaps the packing list is incorrectly specified?)
I try to port gdal 1.9.1
That would be nice!
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
# This is a shell archive. Save it in a file, remove anything before
# this line, and then unpack it by entering sh file. Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
# gdal
# gdal/pkg-plist
# gdal/pkg-descr
# gdal/Makefile
# gdal/distinfo
# gdal/files
# gdal/files/patch-swig-python-GNUmakefile
#
echo c - gdal
mkdir -p gdal /dev/null 21
echo x - gdal/pkg-plist
sed 's/^X//' gdal/pkg-plist 'c2c0c9ac5db08f456dbeb55ec71303b3'
Xbin/gdal-config
Xbin/gdal_contour
Xbin/gdal_grid
Xbin/gdal_rasterize
Xbin/gdal_translate
Xbin/gdaladdo
Xbin/gdalbuildvrt
Xbin/gdaldem
Xbin/gdalenhance
Xbin/gdalinfo
Xbin/gdallocationinfo
Xbin/gdalmanage
Xbin/gdalsrsinfo
Xbin/gdaltindex
Xbin/gdaltransform
Xbin/gdalwarp
Xbin/nearblack
Xbin/ogr2ogr
Xbin/ogrinfo
Xbin/ogrtindex
Xbin/testepsg
Xinclude/cpl_atomic_ops.h
Xinclude/cpl_config.h
Xinclude/cpl_config_extras.h
Xinclude/cpl_conv.h
Xinclude/cpl_csv.h
Xinclude/cpl_error.h
Xinclude/cpl_hash_set.h
Xinclude/cpl_http.h
Xinclude/cpl_list.h
Xinclude/cpl_minixml.h
Xinclude/cpl_minizip_ioapi.h
Xinclude/cpl_minizip_unzip.h
Xinclude/cpl_minizip_zip.h
Xinclude/cpl_multiproc.h
Xinclude/cpl_odbc.h
Xinclude/cpl_port.h
Xinclude/cpl_quad_tree.h
Xinclude/cpl_string.h
Xinclude/cpl_time.h
Xinclude/cpl_vsi.h
Xinclude/cpl_vsi_virtual.h
Xinclude/cpl_win32ce_api.h
Xinclude/cpl_wince.h
Xinclude/cplkeywordparser.h
Xinclude/gdal.h
Xinclude/gdal_alg.h
Xinclude/gdal_alg_priv.h
Xinclude/gdal_csv.h
Xinclude/gdal_frmts.h
Xinclude/gdal_pam.h
Xinclude/gdal_priv.h
Xinclude/gdal_proxy.h
Xinclude/gdal_rat.h
Xinclude/gdal_version.h
Xinclude/gdal_vrt.h
Xinclude/gdalgrid.h
Xinclude/gdaljp2metadata.h
Xinclude/gdalwarper.h
Xinclude/gdalwarpkernel_opencl.h
Xinclude/gvgcpfit.h
Xinclude/memdataset.h
Xinclude/ogr_api.h
Xinclude/ogr_core.h
Xinclude/ogr_feature.h
Xinclude/ogr_featurestyle.h
Xinclude/ogr_geometry.h
Xinclude/ogr_p.h
Xinclude/ogr_spatialref.h
Xinclude/ogr_srs_api.h
Xinclude/ogrsf_frmts.h
Xinclude/rawdataset.h
Xinclude/thinplatespline.h
Xinclude/vrtdataset.h
Xlib/libgdal.a
Xlib/libgdal.la
Xlib/libgdal.so
Xlib/libgdal.so.17
X%%DATADIR%%/GDALLogoBW.svg
X%%DATADIR%%/GDALLogoColor.svg
X%%DATADIR%%/GDALLogoGS.svg
X%%DATADIR%%/LICENSE.TXT
X%%DATADIR%%/compdcs.csv
X%%DATADIR%%/coordinate_axis.csv
X%%DATADIR%%/cubewerx_extra.wkt
X%%DATADIR%%/datum_shift.csv
X%%DATADIR%%/ecw_cs.wkt
X%%DATADIR%%/ellipsoid.csv
X%%DATADIR%%/epsg.wkt
X%%DATADIR%%/esri_StatePlane_extra.wkt
X%%DATADIR%%/esri_Wisconsin_extra.wkt
X%%DATADIR%%/esri_extra.wkt
X%%DATADIR%%/gcs.csv
X%%DATADIR%%/gcs.override.csv
X%%DATADIR%%/gdal_datum.csv
X%%DATADIR%%/gdalicon.png
X%%DATADIR%%/geoccs.csv
X%%DATADIR%%/gt_datum.csv
X%%DATADIR%%/gt_ellips.csv
X%%DATADIR%%/header.dxf
X%%DATADIR%%/nitf_spec.xml
Re: gdal 1.9.1 (Was Re: graphics/gdal 1.9.0 does not build on CURRENT)
On 25.05.2012 21:51 (UTC+1), coder.tuxfamily wrote:
Can you try to build the new port of gdal ?
I have the same problem with swig for php...
Thanks for the update. It builds and installs fine here on two boxes
with 10.0-CURRENT (amd64).
One issue which should be thought about before updating gdal in the ports:
Does gdal-1.9.1 really needs swig 2.0? It seems so for at least libkml?
The problem is, that in your Makefile swig 2.0 conflicts with an
installed swig 1.3.40, which is needed for example by graphics/geos,
graphics/graphviz, math/saga, science/py-scipy and some others.
Affected ports can be found for example with
find /usr/ports -name Makefile -depth 3 -exec grep -l -e swig13 {} \;
I personally would prefer the newer swig 2.0 version (even for most
other ports). Do you think it is necessary to forbid a parallel swig
1.3.40 installation in your port? I read somewhere that both swig ports
can coexist in principle, only some docs share the same places (which
should be changed, of course).
Le 25.05.2012 10:29, Rainer Hurling a écrit :
On 23.05.2012 18:37 (UTC+1), Rainer Hurling wrote:
On 23.05.2012 18:22 (UTC+1), coder.tuxfamily wrote:
OK, I think I get it. This failure does not happen, if swig is not
installed. Then it builds and installs fine.
I tried to install gdal-1.9.0 on another 10.0-CURRENT box and it fails
completely. On that box I was not able to build gdal even without swig
or with swig 2.0 installed.
After that I tried on a 10.0-CURRENT Tinderbox with a totally unmodified
gdal-1.9.0 (even without the ${CPPFLAGS} patch). It builds just fine, no
problems at all!
So it must have to do with some special configurations and/or installed
packages.
The only clue I have at this time is, that
extensions/gdal_wrap.cpp:6845: complains about 'VSIFTruncateL', which
was not declared in this scope.
Do you have any idea what is going wrong with swig here?
OK. Maybe inclue the swig dependancy into the Makefile.
I just tested three cases:
(1) No swig installed - gdal 1.9.0 builds and installs fine
(2) swig 1.3.40 installed - the build breaks, see older mails
(3) swig 2.0.4 installed - gdal 1.9.0 builds and installs fine
So we only have to take care that swig 1.3.40 is not installed.
With swig installed, the pkg-plist of gdal is incomplete, 'make
deinstall' shows
pkg_delete: unable to completely remove directory
'/usr/local/share/gdal'
pkg_delete: unable to completely remove directory
'/usr/local/lib/python2.7/site-packages/GDAL-1.9.0-py2.7-freebsd-10.0-CURRENT-amd64.egg/osgeo'
pkg_delete: unable to completely remove directory
'/usr/local/lib/python2.7/site-packages/GDAL-1.9.0-py2.7-freebsd-10.0-CURRENT-amd64.egg'
pkg_delete: couldn't entirely delete package `gdal-1.9.0'
(perhaps the packing list is incorrectly specified?)
I try to port gdal 1.9.1
That would be nice!
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: graphics/gdal 1.9.0 does not build on CURRENT
On 22.05.2012 22:45 (UTC+1), Rainer Hurling wrote: On 22.05.2012 20:15 (UTC+1), coder.tuxfamily wrote: I have rewrote the patch. Maybe with this new patch... Thanks, but again it gives me the same failure: libtool: compile: cc -DNDEBUG -O2 -pipe -O2 -fno-strict-aliasing -pipe -msse3 -O2 -pipe -O2 -fno-strict-aliasing -pipe -msse3 -Wall -Wdeclaration-after-statement -DOGR_ENABLED -I/usr/local/include -I/usr/ports/graphics/gdal/work/gdal-1.9.0/port -I/usr/local/include -I/usr/local -I/usr/local/include -I/usr/local/include -I/usr/local -I/usr/local/include -I/usr/local -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local -I/usr/local/include -I/usr -I/usr/include -fPIC -I../../port -I../../gcore -I../../alg -I../../ogr/ -I/usr/local/include/python2.7 -I/usr/local/lib/python2.7/site-packages/numpy/core/include -I/usr/ports/graphics/gdal/work/gdal-1.9.0/include -c extensions/gdal_wrap.cpp -fPIC -DPIC -o build/temp.freebsd-10.0-CURRENT-amd64-2.7/extensions/.libs/gdal_wrap.o cc1plus: warning: command line option -Wdeclaration-after-statement is valid for C/ObjC but not for C++ extensions/gdal_wrap.cpp: In function 'PyObject* _wrap_VSIFTruncateL(PyObject*, PyObject*)': extensions/gdal_wrap.cpp:6845: error: 'VSIFTruncateL' was not declared in this scope extensions/gdal_wrap.cpp: In function 'PyObject* _wrap_MajorObject_SetMetadata__SWIG_0(PyObject*, PyObject*)': extensions/gdal_wrap.cpp:7220: warning: deprecated conversion from string constant to 'char*' error: command '/bin/sh' failed with exit status 1 gmake[2]: *** [build] Fehler 1 gmake[2]: Leaving directory `/usr/ports/graphics/gdal/work/gdal-1.9.0/swig/python' gmake[1]: *** [build] Fehler 2 gmake[1]: Leaving directory `/usr/ports/graphics/gdal/work/gdal-1.9.0/swig' gmake: *** [swig-modules] Fehler 2 *** [do-build] Error code 1 Stop in /usr/ports/graphics/gdal. I don't think there is a problem with finding libtool or some python scripts. I will rebuild all my py27- ports and swig, just to be sure. OK, I think I get it. This failure does not happen, if swig is not installed. Then it builds and installs fine. Do you have any idea what is going wrong with swig here? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: graphics/gdal 1.9.0 does not build on CURRENT
OK, I think I get it. This failure does not happen, if swig is not installed. Then it builds and installs fine. Do you have any idea what is going wrong with swig here? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org OK. Maybe inclue the swig dependancy into the Makefile. I try to port gdal 1.9.1 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: graphics/gdal 1.9.0 does not build on CURRENT
On 23.05.2012 18:22 (UTC+1), coder.tuxfamily wrote: OK, I think I get it. This failure does not happen, if swig is not installed. Then it builds and installs fine. Do you have any idea what is going wrong with swig here? OK. Maybe inclue the swig dependancy into the Makefile. I just tested three cases: (1) No swig installed - gdal 1.9.0 builds and installs fine (2) swig 1.3.40 installed - the build breaks, see older mails (3) swig 2.0.4 installed - gdal 1.9.0 builds and installs fine So we only have to take care that swig 1.3.40 is not installed. With swig installed, the pkg-plist of gdal is incomplete, 'make deinstall' shows pkg_delete: unable to completely remove directory '/usr/local/share/gdal' pkg_delete: unable to completely remove directory '/usr/local/lib/python2.7/site-packages/GDAL-1.9.0-py2.7-freebsd-10.0-CURRENT-amd64.egg/osgeo' pkg_delete: unable to completely remove directory '/usr/local/lib/python2.7/site-packages/GDAL-1.9.0-py2.7-freebsd-10.0-CURRENT-amd64.egg' pkg_delete: couldn't entirely delete package `gdal-1.9.0' (perhaps the packing list is incorrectly specified?) I try to port gdal 1.9.1 That would be nice! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: graphics/gdal 1.9.0 does not build on CURRENT
On 22.05.2012 18:50 (UTC+1), coder.tuxfamily wrote: What's your make config ? #make showconfig === The following configuration options are available for gdal-1.9.0: CFITSIO=off FITS support CURL=off Curl support ECW=on ECW JPEG2000 support (THREAD required) EXPAT=on Expat support GEOS=on GEOS support GEOTIFF=on GeoTIFF support GIF=on GIF support GRASS=off GRASS support HDF4=off HDF4 support HDF5=on HDF5 support JASPER=on JPEG 2000 support via jasper JPEG=on JPEG support MYSQL=off MySQL support NETCDF=on NetCDF support ODBC=off ODBC support PERL=off Perl support PGSQL=on PostgreSQL support PHP=off PHP support PNG=on PNG support PROJ=on Projection support via proj PYTHON=on Python support RUBY=off Ruby support SQLITE=off SQLite support THREAD=on Thread support TIFF=on External libtiff XERCES=off Xerces support What's your uname -a ? FreeBSD xxx.xxx.xxx 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r235598: Fri May 18 11:52:38 CEST 2012 x...@xxx.xxx.xxx:/usr/obj/usr/src/sys/XXX amd64 Thank you I really appreciate your help, Rainer ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: graphics/gdal 1.9.0 does not build on CURRENT
I have rewrote the patch.
Maybe with this new patch...
diff -ruN /usr/ports/graphics/gdal/files/patch-configure
gdal/files/patch-configure
--- /usr/ports/graphics/gdal/files/patch-configure 2012-05-19
12:04:43.0 +0200
+++ gdal/files/patch-configure 2012-05-22 19:48:35.0 +0200
@@ -1,6 +1,24 @@
configure.orig 2011-12-23 09:51:45.0 +0800
-+++ configure 2011-12-23 15:30:42.540316668 +0800
-@@ -21140,10 +21140,10 @@
+--- configure.orig 2012-01-04 08:03:42.0 +0100
configure 2012-05-22 19:47:53.0 +0200
+@@ -8908,7 +8908,7 @@
+ LIBTOOL_DEPS=$ltmain
+
+ # Always use our own libtool.
+-LIBTOOL='$(SHELL) $(top_builddir)/libtool'
++LIBTOOL='$(SHELL) /usr/local/bin/libtool'
+
+
+
+@@ -18694,7 +18694,7 @@
+ rm -f testiconv.*
+ echo '#include iconv.h' testiconv.cpp
+ echo 'int main(int argc, char** argv) { iconv_t cd; return iconv (cd,
(const char **) 0, 0, 0, 0); } ' testiconv.cpp
+-if test -z `${CXX} testiconv.cpp -c 21` ; then
++if test -z `${CXX} ${CPPFLAGS} testiconv.cpp -c 21` ; then
+ { $as_echo $as_me:${as_lineno-$LINENO}: result: using
ICONV_CPP_CONST=\const\ 5
+ $as_echo using ICONV_CPP_CONST=\const\ 6; }
+ ICONV_CPP_CONST=const
+@@ -21232,10 +21232,10 @@
if { test -x $ncdump; }; then
{ $as_echo $as_me:${as_lineno-$LINENO}: checking libnetcdf version
with $ncdump 5
$as_echo_n checking libnetcdf version with $ncdump... 6; }
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: graphics/gdal 1.9.0 does not build on CURRENT
On 22.05.2012 20:15 (UTC+1), coder.tuxfamily wrote: I have rewrote the patch. Maybe with this new patch... Thanks, but again it gives me the same failure: libtool: compile: cc -DNDEBUG -O2 -pipe -O2 -fno-strict-aliasing -pipe -msse3 -O2 -pipe -O2 -fno-strict-aliasing -pipe -msse3 -Wall -Wdeclaration-after-statement -DOGR_ENABLED -I/usr/local/include -I/usr/ports/graphics/gdal/work/gdal-1.9.0/port -I/usr/local/include -I/usr/local -I/usr/local/include -I/usr/local/include -I/usr/local -I/usr/local/include -I/usr/local -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local -I/usr/local/include -I/usr -I/usr/include -fPIC -I../../port -I../../gcore -I../../alg -I../../ogr/ -I/usr/local/include/python2.7 -I/usr/local/lib/python2.7/site-packages/numpy/core/include -I/usr/ports/graphics/gdal/work/gdal-1.9.0/include -c extensions/gdal_wrap.cpp -fPIC -DPIC -o build/temp.freebsd-10.0-CURRENT-amd64-2.7/extensions/.libs/gdal_wrap.o cc1plus: warning: command line option -Wdeclaration-after-statement is valid for C/ObjC but not for C++ extensions/gdal_wrap.cpp: In function 'PyObject* _wrap_VSIFTruncateL(PyObject*, PyObject*)': extensions/gdal_wrap.cpp:6845: error: 'VSIFTruncateL' was not declared in this scope extensions/gdal_wrap.cpp: In function 'PyObject* _wrap_MajorObject_SetMetadata__SWIG_0(PyObject*, PyObject*)': extensions/gdal_wrap.cpp:7220: warning: deprecated conversion from string constant to 'char*' error: command '/bin/sh' failed with exit status 1 gmake[2]: *** [build] Fehler 1 gmake[2]: Leaving directory `/usr/ports/graphics/gdal/work/gdal-1.9.0/swig/python' gmake[1]: *** [build] Fehler 2 gmake[1]: Leaving directory `/usr/ports/graphics/gdal/work/gdal-1.9.0/swig' gmake: *** [swig-modules] Fehler 2 *** [do-build] Error code 1 Stop in /usr/ports/graphics/gdal. I don't think there is a problem with finding libtool or some python scripts. I will rebuild all my py27- ports and swig, just to be sure. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: graphics/gdal 1.9.0 does not build on CURRENT
Am 22.05.2012 22:45 (UTC+1) schrieb Rainer Hurling: On 22.05.2012 20:15 (UTC+1), coder.tuxfamily wrote: I have rewrote the patch. Maybe with this new patch... Thanks, but again it gives me the same failure: libtool: compile: cc -DNDEBUG -O2 -pipe -O2 -fno-strict-aliasing -pipe -msse3 -O2 -pipe -O2 -fno-strict-aliasing -pipe -msse3 -Wall -Wdeclaration-after-statement -DOGR_ENABLED -I/usr/local/include -I/usr/ports/graphics/gdal/work/gdal-1.9.0/port -I/usr/local/include -I/usr/local -I/usr/local/include -I/usr/local/include -I/usr/local -I/usr/local/include -I/usr/local -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local -I/usr/local/include -I/usr -I/usr/include -fPIC -I../../port -I../../gcore -I../../alg -I../../ogr/ -I/usr/local/include/python2.7 -I/usr/local/lib/python2.7/site-packages/numpy/core/include -I/usr/ports/graphics/gdal/work/gdal-1.9.0/include -c extensions/gdal_wrap.cpp -fPIC -DPIC -o build/temp.freebsd-10.0-CURRENT-amd64-2.7/extensions/.libs/gdal_wrap.o cc1plus: warning: command line option -Wdeclaration-after-statement is valid for C/ObjC but not for C++ extensions/gdal_wrap.cpp: In function 'PyObject* _wrap_VSIFTruncateL(PyObject*, PyObject*)': extensions/gdal_wrap.cpp:6845: error: 'VSIFTruncateL' was not declared in this scope extensions/gdal_wrap.cpp: In function 'PyObject* _wrap_MajorObject_SetMetadata__SWIG_0(PyObject*, PyObject*)': extensions/gdal_wrap.cpp:7220: warning: deprecated conversion from string constant to 'char*' error: command '/bin/sh' failed with exit status 1 gmake[2]: *** [build] Fehler 1 gmake[2]: Leaving directory `/usr/ports/graphics/gdal/work/gdal-1.9.0/swig/python' gmake[1]: *** [build] Fehler 2 gmake[1]: Leaving directory `/usr/ports/graphics/gdal/work/gdal-1.9.0/swig' gmake: *** [swig-modules] Fehler 2 *** [do-build] Error code 1 Stop in /usr/ports/graphics/gdal. I don't think there is a problem with finding libtool or some python scripts. I will rebuild all my py27- ports and swig, just to be sure. As I assumed, rebuilding py27- and swig ports does not correct my problem. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
graphics/gdal 1.9.0 does not build on CURRENT
Thanks for the update of graphics/gdal to version 1.9.0. It builds fine on 9.0 (amd64), but fails on 10.0-CURRENT (amd64): [..snip..] libtool: compile: c++ -O2 -pipe -O2 -fno-strict-aliasing -pipe -msse3 -Wall -DOGR_ENABLED -I/usr/local/include -I/usr/ports/graphics/gdal/work/gdal-1.9.0/port -I/usr/local/include -I/usr/local -I/usr/local/include -I/usr/local/include -I/usr/local -I/usr/local/include -I/usr/local -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local -I/usr/local/include -I/usr -I/usr/include -DHAVE_LIBZ -c cpl_recode_iconv.cpp -fPIC -DPIC -o .libs/cpl_recode_iconv.o cpl_recode_iconv.cpp: In function 'char* CPLRecodeIconv(const char*, const char*, const char*)': cpl_recode_iconv.cpp:92: error: invalid conversion from 'char**' to 'const char**' cpl_recode_iconv.cpp:92: error: initializing argument 2 of 'size_t libiconv(void*, const char**, size_t*, char**, size_t*)' cpl_recode_iconv.cpp: In function 'char* CPLRecodeFromWCharIconv(const wchar_t*, const char*, const char*)': cpl_recode_iconv.cpp:243: error: invalid conversion from 'char**' to 'const char**' cpl_recode_iconv.cpp:243: error: initializing argument 2 of 'size_t libiconv(void*, const char**, size_t*, char**, size_t*)' gmake[1]: *** [cpl_recode_iconv.lo] Fehler 1 gmake[1]: Leaving directory `/usr/ports/graphics/gdal/work/gdal-1.9.0/port' gmake: *** [port-target] Fehler 2 *** [do-build] Error code 1 Stop in /usr/ports/graphics/gdal. It seems there is a portability issue with ICONV_CPP_CONST like it is described in port/cpl_recode_iconv.cpp:l76ff ? /* */ /* XXX: There is a portability issue: iconv() function could be*/ /* declared differently on different platforms. The second */ /* argument could be declared as char** (as POSIX defines) or */ /* as a const char**. Handle it with the ICONV_CPP_CONST macro here. */ /* */ Please let me know, if you need more details. Thanks again, Rainer P.S.: ports/166605 should be obsolete now? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: graphics/gdal 1.9.0 does not build on CURRENT
Hello,
It's a problem know by GDAL.
In the 1.9.0 with PGSQL, gdal don't build because of include in
cpl_recode_iconv.cpp.
You can corrige this with include ${CPPFLAGS} in configure files.
You can see the trac on OSGeo : http://trac.osgeo.org/gdal/ticket/4525
That will be fix on 1.9.1 version.
Loïc.
Le 21.05.2012 21:23, Rainer Hurling a écrit :
Thanks for the update of graphics/gdal to version 1.9.0.
It builds fine on 9.0 (amd64), but fails on 10.0-CURRENT (amd64):
[..snip..]
libtool: compile: c++ -O2 -pipe -O2 -fno-strict-aliasing -pipe -msse3
-Wall -DOGR_ENABLED -I/usr/local/include
-I/usr/ports/graphics/gdal/work/gdal-1.9.0/port -I/usr/local/include
-I/usr/local -I/usr/local/include -I/usr/local/include -I/usr/local
-I/usr/local/include -I/usr/local -I/usr/local/include
-I/usr/local/include -I/usr/local/include -I/usr/local
-I/usr/local/include -I/usr -I/usr/include -DHAVE_LIBZ -c
cpl_recode_iconv.cpp -fPIC -DPIC -o .libs/cpl_recode_iconv.o
cpl_recode_iconv.cpp: In function 'char* CPLRecodeIconv(const char*,
const char*, const char*)':
cpl_recode_iconv.cpp:92: error: invalid conversion from 'char**' to
'const char**'
cpl_recode_iconv.cpp:92: error: initializing argument 2 of 'size_t
libiconv(void*, const char**, size_t*, char**, size_t*)'
cpl_recode_iconv.cpp: In function 'char* CPLRecodeFromWCharIconv(const
wchar_t*, const char*, const char*)':
cpl_recode_iconv.cpp:243: error: invalid conversion from 'char**' to
'const char**'
cpl_recode_iconv.cpp:243: error: initializing argument 2 of 'size_t
libiconv(void*, const char**, size_t*, char**, size_t*)'
gmake[1]: *** [cpl_recode_iconv.lo] Fehler 1
gmake[1]: Leaving directory `/usr/ports/graphics/gdal/work/gdal-1.9.0/port'
gmake: *** [port-target] Fehler 2
*** [do-build] Error code 1
Stop in /usr/ports/graphics/gdal.
It seems there is a portability issue with ICONV_CPP_CONST like it is
described in port/cpl_recode_iconv.cpp:l76ff ?
/* */
/* XXX: There is a portability issue: iconv() function could be */
/* declared differently on different platforms. The second */
/* argument could be declared as char** (as POSIX defines) or */
/* as a const char**. Handle it with the ICONV_CPP_CONST macro here. */
/* */
Please let me know, if you need more details.
Thanks again,
Rainer
P.S.: ports/166605 should be obsolete now?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: graphics/gdal 1.9.0 does not build on CURRENT
On 21.05.2012 21:37 (UTC+1), coder.tuxfamily wrote:
Hello,
It's a problem know by GDAL.
In the 1.9.0 with PGSQL, gdal don't build because of include in
cpl_recode_iconv.cpp.
You can corrige this with include ${CPPFLAGS} in configure files.
You can see the trac on OSGeo : http://trac.osgeo.org/gdal/ticket/4525
That will be fix on 1.9.1 version.
Wow, thanks for the quick response. So the following patch against the
1.9.0 port does it for me:
--- files/patch-configure.orig 2012-05-19 12:04:43.0 +0200
+++ files/patch-configure 2012-05-21 21:59:47.0 +0200
@@ -1,6 +1,15 @@
configure.orig 2011-12-23 09:51:45.0 +0800
-+++ configure 2011-12-23 15:30:42.540316668 +0800
-@@ -21140,10 +21140,10 @@
+--- configure.orig 2012-01-04 08:03:42.0 +0100
configure 2012-05-21 21:58:56.0 +0200
+@@ -18694,7 +18694,7 @@
+ rm -f testiconv.*
+ echo '#include iconv.h' testiconv.cpp
+ echo 'int main(int argc, char** argv) { iconv_t cd; return iconv
(cd, (const char **) 0, 0, 0, 0); } ' testiconv.cpp
+-if test -z `${CXX} testiconv.cpp -c 21` ; then
++if test -z `${CXX} ${CPPFLAGS} testiconv.cpp -c 21` ; then
+ { $as_echo $as_me:${as_lineno-$LINENO}: result: using
ICONV_CPP_CONST=\const\ 5
+ $as_echo using ICONV_CPP_CONST=\const\ 6; }
+ ICONV_CPP_CONST=const
+@@ -21232,10 +21232,10 @@
if { test -x $ncdump; }; then
{ $as_echo $as_me:${as_lineno-$LINENO}: checking libnetcdf
version with $ncdump 5
$as_echo_n checking libnetcdf version with $ncdump... 6; }
But now I ran into the next problem:
creating build/temp.freebsd-10.0-CURRENT-amd64-2.7/extensions
/bin/sh /usr/local/bin/libtool --mode=compile --tag=CC cc -DNDEBUG -O2
-pipe -O2 -fno-strict-aliasing -pipe -msse3 -O2 -pipe -O2
-fno-strict-aliasing -pipe -msse3 -Wall -Wdeclaration-after-statement
-DOGR_ENABLED -I/usr/local/include
-I/usr/ports/graphics/gdal/work/gdal-1.9.0/port -I/usr/local/include
-I/usr/local -I/usr/local/include -I/usr/local/include -I/usr/local
-I/usr/local/include -I/usr/local -I/usr/local/include
-I/usr/local/include -I/usr/local/include -I/usr/local
-I/usr/local/include -I/usr -I/usr/include -fPIC -I../../port
-I../../gcore -I../../alg -I../../ogr/ -I/usr/local/include/python2.7
-I/usr/local/lib/python2.7/site-packages/numpy/core/include
-I/usr/ports/graphics/gdal/work/gdal-1.9.0/include -c
extensions/gdal_wrap.cpp -o
build/temp.freebsd-10.0-CURRENT-amd64-2.7/extensions/gdal_wrap.o
libtool: compile: cc -DNDEBUG -O2 -pipe -O2 -fno-strict-aliasing -pipe
-msse3 -O2 -pipe -O2 -fno-strict-aliasing -pipe -msse3 -Wall
-Wdeclaration-after-statement -DOGR_ENABLED -I/usr/local/include
-I/usr/ports/graphics/gdal/work/gdal-1.9.0/port -I/usr/local/include
-I/usr/local -I/usr/local/include -I/usr/local/include -I/usr/local
-I/usr/local/include -I/usr/local -I/usr/local/include
-I/usr/local/include -I/usr/local/include -I/usr/local
-I/usr/local/include -I/usr -I/usr/include -fPIC -I../../port
-I../../gcore -I../../alg -I../../ogr/ -I/usr/local/include/python2.7
-I/usr/local/lib/python2.7/site-packages/numpy/core/include
-I/usr/ports/graphics/gdal/work/gdal-1.9.0/include -c
extensions/gdal_wrap.cpp -fPIC -DPIC -o
build/temp.freebsd-10.0-CURRENT-amd64-2.7/extensions/.libs/gdal_wrap.o
cc1plus: warning: command line option -Wdeclaration-after-statement is
valid for C/ObjC but not for C++
extensions/gdal_wrap.cpp: In function 'PyObject*
_wrap_VSIFTruncateL(PyObject*, PyObject*)':
extensions/gdal_wrap.cpp:6845: error: 'VSIFTruncateL' was not declared
in this scope
extensions/gdal_wrap.cpp: In function 'PyObject*
_wrap_MajorObject_SetMetadata__SWIG_0(PyObject*, PyObject*)':
extensions/gdal_wrap.cpp:7220: warning: deprecated conversion from
string constant to 'char*'
error: command '/bin/sh' failed with exit status 1
gmake[2]: *** [build] Fehler 1
gmake[2]: Leaving directory
`/usr/ports/graphics/gdal/work/gdal-1.9.0/swig/python'
gmake[1]: *** [build] Fehler 2
gmake[1]: Leaving directory `/usr/ports/graphics/gdal/work/gdal-1.9.0/swig'
gmake: *** [swig-modules] Fehler 2
*** [do-build] Error code 1
Stop in /usr/ports/graphics/gdal.
Loïc.
Le 21.05.2012 21:23, Rainer Hurling a écrit :
Thanks for the update of graphics/gdal to version 1.9.0.
It builds fine on 9.0 (amd64), but fails on 10.0-CURRENT (amd64):
[..snip..]
libtool: compile: c++ -O2 -pipe -O2 -fno-strict-aliasing -pipe -msse3
-Wall -DOGR_ENABLED -I/usr/local/include
-I/usr/ports/graphics/gdal/work/gdal-1.9.0/port -I/usr/local/include
-I/usr/local -I/usr/local/include -I/usr/local/include -I/usr/local
-I/usr/local/include -I/usr/local -I/usr/local/include
-I/usr/local/include -I/usr/local/include -I/usr/local
-I/usr/local/include -I/usr -I/usr/include -DHAVE_LIBZ -c
cpl_recode_iconv.cpp -fPIC -DPIC -o .libs/cpl_recode_iconv.o
cpl_recode_iconv.cpp: In function 'char* CPLRecodeIconv(const char*,
const char*, const char*)':
cpl_recode_iconv.cpp:92:
Re: graphics/gdal 1.9.0 does not build on CURRENT
Seems to be a problem with python.
Here the diff that i made yesterday.
Courtesly.
Le 21.05.2012 22:13, Rainer Hurling a écrit :
On 21.05.2012 21:37 (UTC+1), coder.tuxfamily wrote:
Hello,
It's a problem know by GDAL.
In the 1.9.0 with PGSQL, gdal don't build because of include in
cpl_recode_iconv.cpp.
You can corrige this with include ${CPPFLAGS} in configure files.
You can see the trac on OSGeo : http://trac.osgeo.org/gdal/ticket/4525
That will be fix on 1.9.1 version.
Wow, thanks for the quick response. So the following patch against the
1.9.0 port does it for me:
--- files/patch-configure.orig 2012-05-19 12:04:43.0 +0200
+++ files/patch-configure 2012-05-21 21:59:47.0 +0200
@@ -1,6 +1,15 @@
configure.orig 2011-12-23 09:51:45.0 +0800
-+++ configure 2011-12-23 15:30:42.540316668 +0800
-@@ -21140,10 +21140,10 @@
+--- configure.orig 2012-01-04 08:03:42.0 +0100
configure 2012-05-21 21:58:56.0 +0200
+@@ -18694,7 +18694,7 @@
+ rm -f testiconv.*
+ echo '#include iconv.h' testiconv.cpp
+ echo 'int main(int argc, char** argv) { iconv_t cd; return iconv (cd,
(const char **) 0, 0, 0, 0); } ' testiconv.cpp
+- if test -z `${CXX} testiconv.cpp -c 21` ; then
++ if test -z `${CXX} ${CPPFLAGS} testiconv.cpp -c 21` ; then
+ { $as_echo $as_me:${as_lineno-$LINENO}: result: using
ICONV_CPP_CONST=\const\ 5
+ $as_echo using ICONV_CPP_CONST=\const\ 6; }
+ ICONV_CPP_CONST=const
+@@ -21232,10 +21232,10 @@
if { test -x $ncdump; }; then
{ $as_echo $as_me:${as_lineno-$LINENO}: checking libnetcdf version with
$ncdump 5
$as_echo_n checking libnetcdf version with $ncdump... 6; }
But now I ran into the next problem:
creating build/temp.freebsd-10.0-CURRENT-amd64-2.7/extensions
/bin/sh /usr/local/bin/libtool --mode=compile --tag=CC cc -DNDEBUG -O2
-pipe -O2 -fno-strict-aliasing -pipe -msse3 -O2 -pipe -O2
-fno-strict-aliasing -pipe -msse3 -Wall -Wdeclaration-after-statement
-DOGR_ENABLED -I/usr/local/include
-I/usr/ports/graphics/gdal/work/gdal-1.9.0/port -I/usr/local/include
-I/usr/local -I/usr/local/include -I/usr/local/include -I/usr/local
-I/usr/local/include -I/usr/local -I/usr/local/include
-I/usr/local/include -I/usr/local/include -I/usr/local
-I/usr/local/include -I/usr -I/usr/include -fPIC -I../../port
-I../../gcore -I../../alg -I../../ogr/ -I/usr/local/include/python2.7
-I/usr/local/lib/python2.7/site-packages/numpy/core/include
-I/usr/ports/graphics/gdal/work/gdal-1.9.0/include -c
extensions/gdal_wrap.cpp -o
build/temp.freebsd-10.0-CURRENT-amd64-2.7/extensions/gdal_wrap.o
libtool: compile: cc -DNDEBUG -O2 -pipe -O2 -fno-strict-aliasing -pipe
-msse3 -O2 -pipe -O2 -fno-strict-aliasing -pipe -msse3 -Wall
-Wdeclaration-after-statement -DOGR_ENABLED -I/usr/local/include
-I/usr/ports/graphics/gdal/work/gdal-1.9.0/port -I/usr/local/include
-I/usr/local -I/usr/local/include -I/usr/local/include -I/usr/local
-I/usr/local/include -I/usr/local -I/usr/local/include
-I/usr/local/include -I/usr/local/include -I/usr/local
-I/usr/local/include -I/usr -I/usr/include -fPIC -I../../port
-I../../gcore -I../../alg -I../../ogr/ -I/usr/local/include/python2.7
-I/usr/local/lib/python2.7/site-packages/numpy/core/include
-I/usr/ports/graphics/gdal/work/gdal-1.9.0/include -c
extensions/gdal_wrap.cpp -fPIC -DPIC -o
build/temp.freebsd-10.0-CURRENT-amd64-2.7/extensions/.libs/gdal_wrap.o
cc1plus: warning: command line option -Wdeclaration-after-statement is
valid for C/ObjC but not for C++
extensions/gdal_wrap.cpp: In function 'PyObject*
_wrap_VSIFTruncateL(PyObject*, PyObject*)':
extensions/gdal_wrap.cpp:6845: error: 'VSIFTruncateL' was not declared
in this scope
extensions/gdal_wrap.cpp: In function 'PyObject*
_wrap_MajorObject_SetMetadata__SWIG_0(PyObject*, PyObject*)':
extensions/gdal_wrap.cpp:7220: warning: deprecated conversion from
string constant to 'char*'
error: command '/bin/sh' failed with exit status 1
gmake[2]: *** [build] Fehler 1
gmake[2]: Leaving directory
`/usr/ports/graphics/gdal/work/gdal-1.9.0/swig/python'
gmake[1]: *** [build] Fehler 2
gmake[1]: Leaving directory `/usr/ports/graphics/gdal/work/gdal-1.9.0/swig'
gmake: *** [swig-modules] Fehler 2
*** [do-build] Error code 1
Stop in /usr/ports/graphics/gdal.
Loïc.
Le 21.05.2012 21:23, Rainer Hurling a écrit :
Thanks for the update of graphics/gdal to version 1.9.0.
It builds fine on 9.0 (amd64), but fails on 10.0-CURRENT (amd64):
[..snip..]
libtool: compile: c++ -O2 -pipe -O2 -fno-strict-aliasing -pipe -msse3
-Wall -DOGR_ENABLED -I/usr/local/include
-I/usr/ports/graphics/gdal/work/gdal-1.9.0/port -I/usr/local/include
-I/usr/local -I/usr/local/include -I/usr/local/include -I/usr/local
-I/usr/local/include -I/usr/local -I/usr/local/include
-I/usr/local/include -I/usr/local/include -I/usr/local
-I/usr/local/include -I/usr -I/usr/include -DHAVE_LIBZ -c
cpl_recode_iconv.cpp -fPIC -DPIC -o .libs/cpl_recode_iconv.o
cpl_recode_iconv.cpp: In function 'char* CPLRecodeIconv(const char*,
const char*, const char*)':
Re: graphics/gdal 1.9.0 does not build on CURRENT
On 21.05.2012 22:20 (UTC+1), coder.tuxfamily wrote:
Seems to be a problem with python.
Here the diff that i made yesterday.
Courtesly.
This patch applies fine, but I get exact the same errors as before (see
below).
There seems to be a problem within extensions/gdal_wrap.cpp.
Rainer
Le 21.05.2012 22:13, Rainer Hurling a écrit :
On 21.05.2012 21:37 (UTC+1), coder.tuxfamily wrote:
Hello,
It's a problem know by GDAL.
In the 1.9.0 with PGSQL, gdal don't build because of include in
cpl_recode_iconv.cpp.
You can corrige this with include ${CPPFLAGS} in configure files.
You can see the trac on OSGeo : http://trac.osgeo.org/gdal/ticket/4525
That will be fix on 1.9.1 version.
Wow, thanks for the quick response. So the following patch against the
1.9.0 port does it for me:
--- files/patch-configure.orig 2012-05-19 12:04:43.0 +0200
+++ files/patch-configure 2012-05-21 21:59:47.0 +0200
@@ -1,6 +1,15 @@
configure.orig 2011-12-23 09:51:45.0 +0800
-+++ configure 2011-12-23 15:30:42.540316668 +0800
-@@ -21140,10 +21140,10 @@
+--- configure.orig 2012-01-04 08:03:42.0 +0100
configure 2012-05-21 21:58:56.0 +0200
+@@ -18694,7 +18694,7 @@
+ rm -f testiconv.*
+ echo '#include iconv.h' testiconv.cpp
+ echo 'int main(int argc, char** argv) { iconv_t cd; return iconv (cd,
(const char **) 0, 0, 0, 0); } ' testiconv.cpp
+- if test -z `${CXX} testiconv.cpp -c 21` ; then
++ if test -z `${CXX} ${CPPFLAGS} testiconv.cpp -c 21` ; then
+ { $as_echo $as_me:${as_lineno-$LINENO}: result: using
ICONV_CPP_CONST=\const\ 5
+ $as_echo using ICONV_CPP_CONST=\const\ 6; }
+ ICONV_CPP_CONST=const
+@@ -21232,10 +21232,10 @@
if { test -x $ncdump; }; then
{ $as_echo $as_me:${as_lineno-$LINENO}: checking libnetcdf version with
$ncdump 5
$as_echo_n checking libnetcdf version with $ncdump... 6; }
But now I ran into the next problem:
creating build/temp.freebsd-10.0-CURRENT-amd64-2.7/extensions
/bin/sh /usr/local/bin/libtool --mode=compile --tag=CC cc -DNDEBUG -O2
-pipe -O2 -fno-strict-aliasing -pipe -msse3 -O2 -pipe -O2
-fno-strict-aliasing -pipe -msse3 -Wall -Wdeclaration-after-statement
-DOGR_ENABLED -I/usr/local/include
-I/usr/ports/graphics/gdal/work/gdal-1.9.0/port -I/usr/local/include
-I/usr/local -I/usr/local/include -I/usr/local/include -I/usr/local
-I/usr/local/include -I/usr/local -I/usr/local/include
-I/usr/local/include -I/usr/local/include -I/usr/local
-I/usr/local/include -I/usr -I/usr/include -fPIC -I../../port
-I../../gcore -I../../alg -I../../ogr/ -I/usr/local/include/python2.7
-I/usr/local/lib/python2.7/site-packages/numpy/core/include
-I/usr/ports/graphics/gdal/work/gdal-1.9.0/include -c
extensions/gdal_wrap.cpp -o
build/temp.freebsd-10.0-CURRENT-amd64-2.7/extensions/gdal_wrap.o
libtool: compile: cc -DNDEBUG -O2 -pipe -O2 -fno-strict-aliasing -pipe
-msse3 -O2 -pipe -O2 -fno-strict-aliasing -pipe -msse3 -Wall
-Wdeclaration-after-statement -DOGR_ENABLED -I/usr/local/include
-I/usr/ports/graphics/gdal/work/gdal-1.9.0/port -I/usr/local/include
-I/usr/local -I/usr/local/include -I/usr/local/include -I/usr/local
-I/usr/local/include -I/usr/local -I/usr/local/include
-I/usr/local/include -I/usr/local/include -I/usr/local
-I/usr/local/include -I/usr -I/usr/include -fPIC -I../../port
-I../../gcore -I../../alg -I../../ogr/ -I/usr/local/include/python2.7
-I/usr/local/lib/python2.7/site-packages/numpy/core/include
-I/usr/ports/graphics/gdal/work/gdal-1.9.0/include -c
extensions/gdal_wrap.cpp -fPIC -DPIC -o
build/temp.freebsd-10.0-CURRENT-amd64-2.7/extensions/.libs/gdal_wrap.o
cc1plus: warning: command line option -Wdeclaration-after-statement is
valid for C/ObjC but not for C++
extensions/gdal_wrap.cpp: In function 'PyObject*
_wrap_VSIFTruncateL(PyObject*, PyObject*)':
extensions/gdal_wrap.cpp:6845: error: 'VSIFTruncateL' was not declared
in this scope
extensions/gdal_wrap.cpp: In function 'PyObject*
_wrap_MajorObject_SetMetadata__SWIG_0(PyObject*, PyObject*)':
extensions/gdal_wrap.cpp:7220: warning: deprecated conversion from
string constant to 'char*'
error: command '/bin/sh' failed with exit status 1
gmake[2]: *** [build] Fehler 1
gmake[2]: Leaving directory
`/usr/ports/graphics/gdal/work/gdal-1.9.0/swig/python'
gmake[1]: *** [build] Fehler 2
gmake[1]: Leaving directory
`/usr/ports/graphics/gdal/work/gdal-1.9.0/swig'
gmake: *** [swig-modules] Fehler 2
*** [do-build] Error code 1
Stop in /usr/ports/graphics/gdal.
Loïc.
Le 21.05.2012 21:23, Rainer Hurling a écrit :
Thanks for the update of graphics/gdal to version 1.9.0.
It builds fine on 9.0 (amd64), but fails on 10.0-CURRENT (amd64):
[..snip..]
libtool: compile: c++ -O2 -pipe -O2 -fno-strict-aliasing -pipe -msse3
-Wall -DOGR_ENABLED -I/usr/local/include
-I/usr/ports/graphics/gdal/work/gdal-1.9.0/port -I/usr/local/include
-I/usr/local -I/usr/local/include -I/usr/local/include -I/usr/local
-I/usr/local/include -I/usr/local -I/usr/local/include
-I/usr/local/include -I/usr/local/include -I/usr/local
