python binding of spatialite (GIS)
Hello, Can someone help me to create the ports of pyspatialite pypi.python.org/pypi/pyspatialite/3.0.1 ? I managed to create the makefile to download the source but my knowledge of python does not allow me to make the port correctly. This binding is need by some extensions in Qgis and maybe other. Thanks. ___ 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
Need advice for a new port ?/libgta
Hello, I finished to make the ports of libgta (http://gta.nongnu.org/libgta.html). But i don't really know what can be the category. Maybe Math because the lib is about Array. What is your advice ? Regards, ___ 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: [CFT] gdal 1.9.1 update and other changes
Le 09.06.2012 08:49, coder.tuxfamily a écrit :
Le 07.06.2012 15:52, Frank Broniewski a écrit :
Yes, that worked.
I tested it with py-gdal. First I had some problems because there were
some other programs depending gdal-grass (QGIS, Grass GIS) which linked
to the older gdal libs, but after deleting gdal-grass, I could import
the module into python and run successfully some tests against some
scripts I had written.
Thank you for the works. I will make tests today with all my
scritps/plugins.
Just a few remarks for now :
- graphics/gdal
Maybe add this options :
ARMADILLOFaster TPS transform computation
CONFIGURE_ARGS+=--with-armadillo=yes
FREEXLFreeXL support
LIB_DEPENDS+=freexl:${PORTSDIR}/textproc/freexl
CONFIGURE_ARGS+=--with-freexl=${LOCALBASE}
MDBInclude MDB driver (need Java)
CONFIGURE_ARGS+=--with-mdb --with-java= ; Maybe with java bindings ?
For PDF (Poppler OR podofo)
POPPLERPoppler support (for PDF)
LIB_DEPENDS+=poppler:${PORTSDIR}/graphics/poppler
CONFIGURE_ARGS+=--with-poppler=${LOCALBASE}
PODOFOPoDoFo support (for PDF)
LIB_DEPENDS+=podofo:${PORTSDIR}/graphics/podofo
CONFIGURE_ARGS+=--with-podofo=${LOCALBASE}
--with-podofo-lib=${LOCALBASE}/lib
SPATIALITESpatialite support
CONFIGURE_ARGS+=--with-spatialite=${LOCALBASE}
I'm working for the other options, but need add some ports (libgdata ;
ogdi ; ESRI GDB Api ; RASDAMAN)
Is it possible to add bindings options directly into graphics/gdal ?
For other bindings :
Maybe add java bindings (for MDB protocol, very useful)
For QGIS port (and maybe other like Grass)
Will need adding py-gdal when python is checked (used by plugins
GdalTools ; fTools ; openlayers ; GoogleLayers ... and many others)
Your works is very helpful thank you !
___
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
My scripts/softs works fine with the new version.
___
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: [CFT] gdal 1.9.1 update and other changes
Le 07.06.2012 15:52, Frank Broniewski a écrit :
Yes, that worked.
I tested it with py-gdal. First I had some problems because there were
some other programs depending gdal-grass (QGIS, Grass GIS) which linked
to the older gdal libs, but after deleting gdal-grass, I could import
the module into python and run successfully some tests against some
scripts I had written.
Thank you for the works. I will make tests today with all my
scritps/plugins.
Just a few remarks for now :
- graphics/gdal
Maybe add this options :
ARMADILLO Faster TPS transform computation
CONFIGURE_ARGS+=--with-armadillo=yes
FREEXL FreeXL support
LIB_DEPENDS+= freexl:${PORTSDIR}/textproc/freexl
CONFIGURE_ARGS+=--with-freexl=${LOCALBASE}
MDB Include MDB driver (need Java)
CONFIGURE_ARGS+=--with-mdb --with-java= ; Maybe with java bindings ?
For PDF (Poppler OR podofo)
POPPLER Poppler support (for PDF)
LIB_DEPENDS+= poppler:${PORTSDIR}/graphics/poppler
CONFIGURE_ARGS+=--with-poppler=${LOCALBASE}
PODOFO PoDoFo support (for PDF)
LIB_DEPENDS+= podofo:${PORTSDIR}/graphics/podofo
CONFIGURE_ARGS+=--with-podofo=${LOCALBASE}
--with-podofo-lib=${LOCALBASE}/lib
SPATIALITE Spatialite support
CONFIGURE_ARGS+=--with-spatialite=${LOCALBASE}
I'm working for the other options, but need add some ports (libgdata ;
ogdi ; ESRI GDB Api ; RASDAMAN)
Is it possible to add bindings options directly into graphics/gdal ?
For other bindings :
Maybe add java bindings (for MDB protocol, very useful)
For QGIS port (and maybe other like Grass)
Will need adding py-gdal when python is checked (used by plugins
GdalTools ; fTools ; openlayers ; GoogleLayers ... and many others)
Your works is very helpful thank you !
___
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
ports/168215: [PATCH] print/scribus-devel: update to 1.5.0 svn
I'm trying to fix errors with scribus-devel, but i don't understand differences between port test and tinderbox. You can find my logs and my shar here : http://download.tuxfamily.org/bartcoding/FreeBSD/Scribus-devel.tar.gz Is there somene who can make tests ? Regards. ___ 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: make failed for editors/libreoffice
Le 05.06.2012 05:48, Heino Tiedemann a écrit : Leslie Jensenles...@eskk.nu wrote: --- Oh dear - something failed during the build - sorry ! For more help with debugging build errors, please see the section in: http://wiki.documentfoundation.org/Development internal build errors: ERROR: error 65280 occurred while making /usr/ports/editors/libreoffice/work/libreoffice-core-3.5.2.2/vcl/prj it seems that the error is inside 'vcl', please re-run build inside this module to isolate the error and/or test your fix: --- /usr/local/bin/bash cd /usr/ports/editors/libreoffice/work/libreoffice-core-3.5.2.2 source ./Env.Host.sh cd vcl gmake clean # optional gmake -r when the problem is isolated and fixed exit and re-run 'make' from the top-level gmake[1]: *** [build] Fel 1 gmake[1]: Lämnar katalogen /usr/ports/editors/libreoffice/work/libreoffice-core-3.5.2.2 gmake: *** [source-env-and-recurse] Fel 2 *** Error code 1 Stop in /usr/ports/editors/libreoffice. I have this again, again and again in a lot of modules: - vlc - framework - sfx2 - ... In this way I need a lot of days to build Libreoffice. Because I cannot watch the build process all the time - every day some build error occurded, und I have to fix it by hand. Heino ___ 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 I have the same problem but i can pass it except for tail_build. My options : GTK3 (I don't remember, but maybe tested also with GTK2) JAVA MMEDIA PGSQL SVG Regards ___ 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 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)
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)
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)
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
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
X%%DATADIR
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
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
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
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: Wbar not displaying correctly
Hello, For Problem load font file it's a problem with you conf. Run wbar-config. Go into Preferences and choose your font. Usually : /usr/local/lib/X11/fonts/dejavu/DejaVuSans Le 09.05.2012 13:41, Leslie Jensen a écrit : I've upgraded one system from 8.2-RELEASE to 8.3-RELEASE. Rebuild all ports with portmaster after the upgrade. My problem is that Wbar now displays the first applications icon as background picture. If I move another application to the top position its icon will be displayed as the background. I start wbar with the following command in a script that's auto started in XFCE. wbar -above-desk -bpress -pos bottom I get the following when starting from the command line Problem load font file. TerminalEmulator Here TerminalEmulator is my first application. It'll change if I move another application to the top. I've tried to recompile with portmaster -rf x11/wbar but there's no change in behaviour. I have two other systems running 8.2 with exactly the same set up and there wbar is not displaying this behaviour. Any hints appreciated Thanks /Leslie ___ 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
