Re: gdal
Am 02.05.21 um 19:55 schrieb LuMiWa via freebsd-ports:
> Hi!
>
> I have a problem to build graphics/gdal on FreeBSD-13.0-RELEASE:
> m::seekp' declared here: type mismatch at 1st parameter ('uint64_t'
> (aka 'unsigned long') vs 'GInt64' (aka 'long long')) virtual void
> seekp (uint64_t pos) = 0; ^
> exrdataset.cpp:495:1: error: unknown type name 'Int64'; did you mean
> 'GInt64'? Int64 GDALEXRIOStream::tellg ()
> ^
> GInt64
> /usr/ports/graphics/gdal/work/gdal-3.2.2/port/cpl_port.h:267:26: note:
> 'GInt64' declared here typedef GIntBig GInt64;
> ^
> exrdataset.cpp:497:24: error: unknown type name 'Int64'; did you mean
> 'GInt64'? return static_cast(VSIFTellL(m_fp));
>^
> GInt64
> /usr/ports/graphics/gdal/work/gdal-3.2.2/port/cpl_port.h:267:26: note:
> 'GInt64' declared here typedef GIntBig GInt64;
> ^
> exrdataset.cpp:500:30: error: unknown type name 'Int64'; did you mean
> 'GInt64'? void GDALEXRIOStream::seekg (Int64 pos)
> ^
> GInt64
> /usr/ports/graphics/gdal/work/gdal-3.2.2/port/cpl_port.h:267:26: note:
> 'GInt64' declared here typedef GIntBig GInt64;
> ^
> exrdataset.cpp:566:36: error: allocating an object of abstract class
> type 'GDALEXRIOStream' poDS->m_pIStream.reset(new GDALEXRIOStream(fp,
> osFilename)); ^
> exrdataset.cpp:992:25: error: variable type 'GDALEXRIOStream' is an
> abstract class GDALEXRIOStream ostream(fp, pszFilename);
> ^
> exrdataset.cpp:1984:32: error: allocating an object of abstract class
> type 'GDALEXRIOStream' poDS->m_pOStream.reset(new GDALEXRIOStream(fp,
> pszFilename)); ^
> 3 warnings and 14 errors generated.
> gmake[4]: *** [../../GDALmake.opt:646: ../o/exrdataset.o] Error 1
> gmake[4]: Leaving directory
> '/usr/ports/graphics/gdal/work/gdal-3.2.2/frmts/exr' gmake[3]: ***
> [GNUmakefile:15: exr-install-obj] Error 2 gmake[3]: Leaving directory
> '/usr/ports/graphics/gdal/work/gdal-3.2.2/frmts' gmake[2]: ***
> [GNUmakefile:114: frmts-target] Error 2 gmake[2]: Leaving directory
> '/usr/ports/graphics/gdal/work/gdal-3.2.2' *** Error code 1
>
> Stop.
> make[1]: stopped in /usr/ports/graphics/gdal
> *** Error code 1
>
> Thank you.
>
>
I just opened a PR with a patch, which should solve the issue ;)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255592
HTH,
Rainer
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: gdal
On Mon, 3 May 2021 12:42:00 +0200
Matthieu Volat wrote:
> On Sun, 2 May 2021 13:55:45 -0400
> LuMiWa via freebsd-ports wrote:
>
> > Hi!
> >
> > I have a problem to build graphics/gdal on FreeBSD-13.0-RELEASE:
> > m::seekp' declared here: type mismatch at 1st parameter ('uint64_t'
> > (aka 'unsigned long') vs 'GInt64' (aka 'long long')) virtual void
> > seekp (uint64_t pos) = 0; ^
> > exrdataset.cpp:495:1: error: unknown type name 'Int64'; did you mean
> > 'GInt64'? Int64 GDALEXRIOStream::tellg ()
> > ^
> > GInt64
> > /usr/ports/graphics/gdal/work/gdal-3.2.2/port/cpl_port.h:267:26:
> > note: 'GInt64' declared here typedef GIntBig GInt64;
> > ^
> > exrdataset.cpp:497:24: error: unknown type name 'Int64'; did you
> > mean 'GInt64'? return static_cast(VSIFTellL(m_fp));
> >^
> >GInt64
> > /usr/ports/graphics/gdal/work/gdal-3.2.2/port/cpl_port.h:267:26:
> > note: 'GInt64' declared here typedef GIntBig GInt64;
> > ^
> > exrdataset.cpp:500:30: error: unknown type name 'Int64'; did you
> > mean 'GInt64'? void GDALEXRIOStream::seekg (Int64 pos)
> > ^
> > GInt64
> > /usr/ports/graphics/gdal/work/gdal-3.2.2/port/cpl_port.h:267:26:
> > note: 'GInt64' declared here typedef GIntBig GInt64;
> > ^
> > exrdataset.cpp:566:36: error: allocating an object of abstract class
> > type 'GDALEXRIOStream' poDS->m_pIStream.reset(new
> > GDALEXRIOStream(fp, osFilename)); ^
> > exrdataset.cpp:992:25: error: variable type 'GDALEXRIOStream' is an
> > abstract class GDALEXRIOStream ostream(fp, pszFilename);
> > ^
> > exrdataset.cpp:1984:32: error: allocating an object of abstract
> > class type 'GDALEXRIOStream' poDS->m_pOStream.reset(new
> > GDALEXRIOStream(fp, pszFilename)); ^
> > 3 warnings and 14 errors generated.
> > gmake[4]: *** [../../GDALmake.opt:646: ../o/exrdataset.o] Error 1
> > gmake[4]: Leaving directory
> > '/usr/ports/graphics/gdal/work/gdal-3.2.2/frmts/exr' gmake[3]: ***
> > [GNUmakefile:15: exr-install-obj] Error 2 gmake[3]: Leaving
> > directory '/usr/ports/graphics/gdal/work/gdal-3.2.2/frmts'
> > gmake[2]: *** [GNUmakefile:114: frmts-target] Error 2 gmake[2]:
> > Leaving directory '/usr/ports/graphics/gdal/work/gdal-3.2.2' ***
> > Error code 1
> >
> > Stop.
> > make[1]: stopped in /usr/ports/graphics/gdal
> > *** Error code 1
> >
> > Thank you.
> >
>
> Hi, this happens indeed when you build gdal *without* the EXR option
> when openexr is present at build time. I guess the off option is not
> passed correctly to the configure script?
>
> Cheers,
>
> -- Matthieu Volat
Thank you very much.
--
“Two things are infinite: the universe and human stupidity; and I'm not
sure about the universe.”
― Albert Einstein
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: gdal
On 03/05/2021 12:42, Matthieu Volat wrote: Hi, this happens indeed when you build gdal*without* the EXR option when openexr is present at build time. I guess the off option is not passed correctly to the configure script? Hi Mathieu, LuMiWa, I ran in the very same problem, with the *default* (make rmconfig) options. As you mention, enabling EXR option fixes this Cheers, Xavier -- Xavier HUMBERT - Unix/Win/MacOSX Sysadmin/Network Senior Engineer https://www.amdh.fr ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: gdal
On Sun, 2 May 2021 13:55:45 -0400
LuMiWa via freebsd-ports wrote:
> Hi!
>
> I have a problem to build graphics/gdal on FreeBSD-13.0-RELEASE:
> m::seekp' declared here: type mismatch at 1st parameter ('uint64_t'
> (aka 'unsigned long') vs 'GInt64' (aka 'long long')) virtual void
> seekp (uint64_t pos) = 0; ^
> exrdataset.cpp:495:1: error: unknown type name 'Int64'; did you mean
> 'GInt64'? Int64 GDALEXRIOStream::tellg ()
> ^
> GInt64
> /usr/ports/graphics/gdal/work/gdal-3.2.2/port/cpl_port.h:267:26: note:
> 'GInt64' declared here typedef GIntBig GInt64;
> ^
> exrdataset.cpp:497:24: error: unknown type name 'Int64'; did you mean
> 'GInt64'? return static_cast(VSIFTellL(m_fp));
>^
> GInt64
> /usr/ports/graphics/gdal/work/gdal-3.2.2/port/cpl_port.h:267:26: note:
> 'GInt64' declared here typedef GIntBig GInt64;
> ^
> exrdataset.cpp:500:30: error: unknown type name 'Int64'; did you mean
> 'GInt64'? void GDALEXRIOStream::seekg (Int64 pos)
> ^
> GInt64
> /usr/ports/graphics/gdal/work/gdal-3.2.2/port/cpl_port.h:267:26: note:
> 'GInt64' declared here typedef GIntBig GInt64;
> ^
> exrdataset.cpp:566:36: error: allocating an object of abstract class
> type 'GDALEXRIOStream' poDS->m_pIStream.reset(new GDALEXRIOStream(fp,
> osFilename)); ^
> exrdataset.cpp:992:25: error: variable type 'GDALEXRIOStream' is an
> abstract class GDALEXRIOStream ostream(fp, pszFilename);
> ^
> exrdataset.cpp:1984:32: error: allocating an object of abstract class
> type 'GDALEXRIOStream' poDS->m_pOStream.reset(new GDALEXRIOStream(fp,
> pszFilename)); ^
> 3 warnings and 14 errors generated.
> gmake[4]: *** [../../GDALmake.opt:646: ../o/exrdataset.o] Error 1
> gmake[4]: Leaving directory
> '/usr/ports/graphics/gdal/work/gdal-3.2.2/frmts/exr' gmake[3]: ***
> [GNUmakefile:15: exr-install-obj] Error 2 gmake[3]: Leaving directory
> '/usr/ports/graphics/gdal/work/gdal-3.2.2/frmts' gmake[2]: ***
> [GNUmakefile:114: frmts-target] Error 2 gmake[2]: Leaving directory
> '/usr/ports/graphics/gdal/work/gdal-3.2.2' *** Error code 1
>
> Stop.
> make[1]: stopped in /usr/ports/graphics/gdal
> *** Error code 1
>
> Thank you.
>
Hi, this happens indeed when you build gdal *without* the EXR option when
openexr is present at build time. I guess the off option is not passed
correctly to the configure script?
Cheers,
-- Matthieu Volat
pgpGCWQ4vBdwa.pgp
Description: OpenPGP digital signature
Re: gdal
On Sun, 2 May 2021 20:14:12 +0200 Loïc Bartoletti wrote: > Hi, > > What's your options? How do you build it? > > Thanks. > > Loïc > I built with the default options. I am using portmaster and I try cd /usr/oprts/graphics/gdal and make but the same result -- “Two things are infinite: the universe and human stupidity; and I'm not sure about the universe.” ― Albert Einstein ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: gdal
Hi,
What's your options? How do you build it?
Thanks.
Loïc
Le 02/05/2021 à 19:55, LuMiWa via freebsd-ports a écrit :
Hi!
I have a problem to build graphics/gdal on FreeBSD-13.0-RELEASE:
m::seekp' declared here: type mismatch at 1st parameter ('uint64_t'
(aka 'unsigned long') vs 'GInt64' (aka 'long long')) virtual void
seekp (uint64_t pos) = 0; ^
exrdataset.cpp:495:1: error: unknown type name 'Int64'; did you mean
'GInt64'? Int64 GDALEXRIOStream::tellg ()
^
GInt64
/usr/ports/graphics/gdal/work/gdal-3.2.2/port/cpl_port.h:267:26: note:
'GInt64' declared here typedef GIntBig GInt64;
^
exrdataset.cpp:497:24: error: unknown type name 'Int64'; did you mean
'GInt64'? return static_cast(VSIFTellL(m_fp));
^
GInt64
/usr/ports/graphics/gdal/work/gdal-3.2.2/port/cpl_port.h:267:26: note:
'GInt64' declared here typedef GIntBig GInt64;
^
exrdataset.cpp:500:30: error: unknown type name 'Int64'; did you mean
'GInt64'? void GDALEXRIOStream::seekg (Int64 pos)
^
GInt64
/usr/ports/graphics/gdal/work/gdal-3.2.2/port/cpl_port.h:267:26: note:
'GInt64' declared here typedef GIntBig GInt64;
^
exrdataset.cpp:566:36: error: allocating an object of abstract class
type 'GDALEXRIOStream' poDS->m_pIStream.reset(new GDALEXRIOStream(fp,
osFilename)); ^
exrdataset.cpp:992:25: error: variable type 'GDALEXRIOStream' is an
abstract class GDALEXRIOStream ostream(fp, pszFilename);
^
exrdataset.cpp:1984:32: error: allocating an object of abstract class
type 'GDALEXRIOStream' poDS->m_pOStream.reset(new GDALEXRIOStream(fp,
pszFilename)); ^
3 warnings and 14 errors generated.
gmake[4]: *** [../../GDALmake.opt:646: ../o/exrdataset.o] Error 1
gmake[4]: Leaving directory
'/usr/ports/graphics/gdal/work/gdal-3.2.2/frmts/exr' gmake[3]: ***
[GNUmakefile:15: exr-install-obj] Error 2 gmake[3]: Leaving directory
'/usr/ports/graphics/gdal/work/gdal-3.2.2/frmts' gmake[2]: ***
[GNUmakefile:114: frmts-target] Error 2 gmake[2]: Leaving directory
'/usr/ports/graphics/gdal/work/gdal-3.2.2' *** Error code 1
Stop.
make[1]: stopped in /usr/ports/graphics/gdal
*** Error code 1
Thank you.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
gdal
Hi!
I have a problem to build graphics/gdal on FreeBSD-13.0-RELEASE:
m::seekp' declared here: type mismatch at 1st parameter ('uint64_t'
(aka 'unsigned long') vs 'GInt64' (aka 'long long')) virtual void
seekp (uint64_t pos) = 0; ^
exrdataset.cpp:495:1: error: unknown type name 'Int64'; did you mean
'GInt64'? Int64 GDALEXRIOStream::tellg ()
^
GInt64
/usr/ports/graphics/gdal/work/gdal-3.2.2/port/cpl_port.h:267:26: note:
'GInt64' declared here typedef GIntBig GInt64;
^
exrdataset.cpp:497:24: error: unknown type name 'Int64'; did you mean
'GInt64'? return static_cast(VSIFTellL(m_fp));
^
GInt64
/usr/ports/graphics/gdal/work/gdal-3.2.2/port/cpl_port.h:267:26: note:
'GInt64' declared here typedef GIntBig GInt64;
^
exrdataset.cpp:500:30: error: unknown type name 'Int64'; did you mean
'GInt64'? void GDALEXRIOStream::seekg (Int64 pos)
^
GInt64
/usr/ports/graphics/gdal/work/gdal-3.2.2/port/cpl_port.h:267:26: note:
'GInt64' declared here typedef GIntBig GInt64;
^
exrdataset.cpp:566:36: error: allocating an object of abstract class
type 'GDALEXRIOStream' poDS->m_pIStream.reset(new GDALEXRIOStream(fp,
osFilename)); ^
exrdataset.cpp:992:25: error: variable type 'GDALEXRIOStream' is an
abstract class GDALEXRIOStream ostream(fp, pszFilename);
^
exrdataset.cpp:1984:32: error: allocating an object of abstract class
type 'GDALEXRIOStream' poDS->m_pOStream.reset(new GDALEXRIOStream(fp,
pszFilename)); ^
3 warnings and 14 errors generated.
gmake[4]: *** [../../GDALmake.opt:646: ../o/exrdataset.o] Error 1
gmake[4]: Leaving directory
'/usr/ports/graphics/gdal/work/gdal-3.2.2/frmts/exr' gmake[3]: ***
[GNUmakefile:15: exr-install-obj] Error 2 gmake[3]: Leaving directory
'/usr/ports/graphics/gdal/work/gdal-3.2.2/frmts' gmake[2]: ***
[GNUmakefile:114: frmts-target] Error 2 gmake[2]: Leaving directory
'/usr/ports/graphics/gdal/work/gdal-3.2.2' *** Error code 1
Stop.
make[1]: stopped in /usr/ports/graphics/gdal
*** Error code 1
Thank you.
--
“Two things are infinite: the universe and human stupidity; and I'm not
sure about the universe.”
― Albert Einstein
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Can't makepatch to a port (graphics/py-gdal)
On 19/01/2018 09:01, L.Bartoletti wrote:
Hi,
A dummy question, but, I haven't be able to make a simple patch to a
port (graphics/py-gdal).
My patch (using diff -u) is:
--- swig/include/gdal_array.i.orig 2018-01-19
06:46:50.571482000 +0100
+++ swig/include/gdal_array.i 2018-01-19 06:46:50.571393000 +0100
@@ -1065,6 +1065,7 @@
%pythoncode %{
import numpy
+from . import _gdal_array
import gdalconst
import gdal
> make makepatch
produces nothing
running the "make patch", I got
===> Patching for py27-gdal-2.2.3
===> Applying FreeBSD patches for py27-gdal-2.2.3
File to patch:
and unable to apply the patch.
Any hint?
Hello/
The port has
WRKSRC_SUBDIR= swig/python
Everything, including 'make patch' is running inside this dir.
swig/include is not there.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Can't makepatch to a port (graphics/py-gdal)
Hi,
A dummy question, but, I haven't be able to make a simple patch to a
port (graphics/py-gdal).
My patch (using diff -u) is:
--- swig/include/gdal_array.i.orig 2018-01-19
06:46:50.571482000 +0100
+++ swig/include/gdal_array.i 2018-01-19 06:46:50.571393000 +0100
@@ -1065,6 +1065,7 @@
%pythoncode %{
import numpy
+from . import _gdal_array
import gdalconst
import gdal
> make makepatch
produces nothing
running the "make patch", I got
===> Patching for py27-gdal-2.2.3
===> Applying FreeBSD patches for py27-gdal-2.2.3
File to patch:
and unable to apply the patch.
Any hint?
Regards
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
graphics/gdal: /lib/libgcc_s.so.1 problem
For some time now, I get the following message, when I use some of the GDAL tools (graphics/gdal) on FreeBSD HEAD (11.0-CURRENT r278036). For example, if I try: #gdalinfo --version ERROR 1: /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc48/libgfortran.so.3 not found ERROR 1: /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc48/libgfortran.so.3 not found GDAL 1.11.1, released 2014/09/24 Because of this, GDAL is not usable for me with ports like math/saga or graphics/qgis on HEAD. They core dump right after starting them. The port graphics/gdal itself builds and installs fine. Don't know, if this is relevant: On my boxes, devel/libc++ is installed by other ports. Obviously, there is something odd between clang (base) and gcc (ports). Is this a known problem? Thanks for any help. Regards, Rainer Hurling ___ 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/p5-Geo-GDAL: Does not build on CURRENT
Nobody else seeing this error on recent 10.0-CURRENT (amd64, clang)?
Thanks in advance for any help,
Rainer Hurling
#make -DMAKE_JOBS_UNSAFE=yes
=== License MIT accepted by the user
=== Fetching all distfiles required by p5-Geo-GDAL-1.10.1 for building
=== Extracting for p5-Geo-GDAL-1.10.1
= SHA256 Checksum OK for gdal-1.10.1.tar.gz.
=== Patching for p5-Geo-GDAL-1.10.1
=== p5-Geo-GDAL-1.10.1 depends on file: /usr/local/bin/perl5.16.3 - found
=== p5-Geo-GDAL-1.10.1 depends on shared library: gdal - found
=== Configuring for p5-Geo-GDAL-1.10.1
=== FreeBSD 10 autotools fix applied to
/usr/ports/graphics/p5-Geo-GDAL/work/gdal-1.10.1/m4/acinclude.m4
=== FreeBSD 10 autotools fix applied to
/usr/ports/graphics/p5-Geo-GDAL/work/gdal-1.10.1/m4/libtool.m4
=== FreeBSD 10 autotools fix applied to
/usr/ports/graphics/p5-Geo-GDAL/work/gdal-1.10.1/frmts/grass/pkg/configure
=== FreeBSD 10 autotools fix applied to
/usr/ports/graphics/p5-Geo-GDAL/work/gdal-1.10.1/frmts/grass/pkg/aclocal.m4
=== FreeBSD 10 autotools fix applied to
/usr/ports/graphics/p5-Geo-GDAL/work/gdal-1.10.1/frmts/iso8211/aclocal.m4
=== FreeBSD 10 autotools fix applied to
/usr/ports/graphics/p5-Geo-GDAL/work/gdal-1.10.1/frmts/sdts/aclocal.m4
=== FreeBSD 10 autotools fix applied to
/usr/ports/graphics/p5-Geo-GDAL/work/gdal-1.10.1/configure
=== FreeBSD 10 autotools fix applied to
/usr/ports/graphics/p5-Geo-GDAL/work/gdal-1.10.1/aclocal.m4
=== Building for p5-Geo-GDAL-1.10.1
--- Makefile_Geo__GDAL ---
perl Makefile.PL INSTALL_BASE=
Found /usr/local/bin/gdal-config
Using /usr/local/bin/gdal-config.
Building against GDAL defined in /usr/local/bin/gdal-config
Unrecognized argument in LIBS ignored: '-pthread'
Writing Makefile_Geo__OGR for Geo::OGR
Writing MYMETA.yml and MYMETA.json
Unrecognized argument in LIBS ignored: '-pthread'
Writing Makefile_Geo__GDAL__Const for Geo::GDAL::Const
Writing MYMETA.yml and MYMETA.json
Unrecognized argument in LIBS ignored: '-pthread'
Writing Makefile_Geo__OSR for Geo::OSR
Writing MYMETA.yml and MYMETA.json
Unrecognized argument in LIBS ignored: '-pthread'
Writing Makefile_Geo__GDAL for Geo::GDAL
Writing MYMETA.yml and MYMETA.json
--- build ---
/usr/bin/make -f Makefile_Geo__GDAL
--- blib/lib/Geo/.exists ---
--- blib/arch/.exists ---
--- blib/lib/auto/Geo/GDAL/.exists ---
--- blib/arch/auto/Geo/GDAL/.exists ---
--- blib/bin/.exists ---
--- blib/script/.exists ---
--- blib/man1/.exists ---
--- blib/man3/.exists ---
--- subdirs ---
--- GDAL.bs ---
Running Mkbootstrap for Geo::GDAL ()
--- gdal_wrap.o ---
cc -c -I/usr/local/include
-DAPPLLIB_EXP=/usr/local/lib/perl5/5.16/BSDPAN -DHAS_FPSETMASK
-DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -fstack-protector
-I/usr/local/include -O2 -pipe -fno-strict-aliasing
-DVERSION=\1.9911\ -DXS_VERSION=\1.9911\ -DPIC -fPIC
-I/usr/local/lib/perl5/5.16/mach/CORE gdal_wrap.cpp
--- GDAL.bs ---
chmod 644 GDAL.bs
--- pm_to_blib ---
cp lib/Geo/OGR.pm blib/lib/Geo/OGR.pm
cp lib/Geo/GDAL/Const.pm blib/lib/Geo/GDAL/Const.pm
cp lib/Geo/GDAL.pm blib/lib/Geo/GDAL.pm
cp lib/Geo/OSR.pm blib/lib/Geo/OSR.pm
--- blibdirs ---
--- blib/arch/auto/Geo/GDAL/GDAL.bs ---
cp GDAL.bs blib/arch/auto/Geo/GDAL/GDAL.bs
chmod 644 blib/arch/auto/Geo/GDAL/GDAL.bs
--- config ---
--- gdal_wrap.o ---
gdal_wrap.cpp:4500:12: error: assigning to 'char *' from incompatible
type 'const char *'
arg1 = (const char *);
^
gdal_wrap.cpp:4648:12: error: assigning to 'char *' from incompatible
type 'const char *'
arg2 = (const char *);
^
gdal_wrap.cpp:4719:12: error: assigning to 'char *' from incompatible
type 'const char *'
arg1 = (const char *);
^
gdal_wrap.cpp:4806:12: error: assigning to 'char *' from incompatible
type 'const char *'
arg1 = (const char *);
^
gdal_wrap.cpp:5173:12: error: assigning to 'char *' from incompatible
type 'const char *'
arg1 = (const char *);
^
gdal_wrap.cpp:5251:12: error: assigning to 'char *' from incompatible
type 'const char *'
arg1 = (const char *);
^
gdal_wrap.cpp:5353:12: error: assigning to 'char *' from incompatible
type 'const char *'
arg1 = (const char *);
^
gdal_wrap.cpp:5420:12: error: assigning to 'char *' from incompatible
type 'const char *'
arg1 = (const char *);
^
gdal_wrap.cpp:5543:12: error: assigning to 'char *' from incompatible
type 'const char *'
arg1 = (const char *);
^
gdal_wrap.cpp:5639:12: error: assigning to 'char *' from incompatible
type 'const char *'
arg1 = (const char *);
^
gdal_wrap.cpp:6293:16: warning: using the result of an assignment as a
condition without parentheses [-Wparentheses]
while(sv = hv_iternextsv(hv,key,klen)) {
~~~^~
gdal_wrap.cpp:6293:16: note
Re: GDAL 1.10 build fails on FreeBSD
Am 2013-09-03 16:54, schrieb Rainer Hurling: Am 03.09.2013 15:11, schrieb Frank Broniewski: Hi all, I tried updating Gdal to the latest version on my FreeBSD system (9.1-RELEASE-p6), but the build fails: snip c postgisrasterdataset.cpp -fPIC -DPIC -o ../o/.libs/postgisrasterdataset.o postgisrasterdataset.cpp: In function 'void GDALRegister_PostGISRaster()': postgisrasterdataset.cpp:2096: error: 'GDAL_DMD_SUBDATASETS' was not declared in this scope gmake[2]: *** [../o/postgisrasterdataset.lo] Error 1 gmake[2]: Leaving directory `/usr/ports/graphics/gdal/work/gdal-1.10.1/frmts/postgisraster' gmake[1]: *** [postgisraster-install-obj] Error 2 gmake[1]: Leaving directory `/usr/ports/graphics/gdal/work/gdal-1.10.1/frmts' gmake: *** [frmts-target] Error 2 *** [do-build] Error code 1 /snip PostGIS is POSTGIS=1.5.3 GEOS=3.3.8-CAPI-1.7.8 PROJ=Rel. 4.8.0, 6 March 2012 LIBXML=2.7.8 USE_STATS (procs from 1.5 r5385 need upgrade) so apparently no raster support ... Is this a port issue or shall I report it to the GDAL crew? This has been reported before. There is a conflict between old and new include/gdal.h, see also UPDATING 20130831. Uninstalling the old graphics/gdal before building the new one should work. HTH, Rainer Rainer, thanks for your help. I was updating mapserver when gdal got into the updating queue, so I didn't check UPDATING for gdal, only for mapserver. Lesson learned :-) Frank Frank -- Frank BRONIEWSKI METRICO s.à r.l. géomètres technologies d'information géographique rue des Romains 36 L-5433 NIEDERDONVEN tél.: +352 26 74 94 - 28 fax.: +352 26 74 94 99 http://www.metrico.lu ___ 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.10 build fails on FreeBSD
Hi all, I tried updating Gdal to the latest version on my FreeBSD system (9.1-RELEASE-p6), but the build fails: snip c postgisrasterdataset.cpp -fPIC -DPIC -o ../o/.libs/postgisrasterdataset.o postgisrasterdataset.cpp: In function 'void GDALRegister_PostGISRaster()': postgisrasterdataset.cpp:2096: error: 'GDAL_DMD_SUBDATASETS' was not declared in this scope gmake[2]: *** [../o/postgisrasterdataset.lo] Error 1 gmake[2]: Leaving directory `/usr/ports/graphics/gdal/work/gdal-1.10.1/frmts/postgisraster' gmake[1]: *** [postgisraster-install-obj] Error 2 gmake[1]: Leaving directory `/usr/ports/graphics/gdal/work/gdal-1.10.1/frmts' gmake: *** [frmts-target] Error 2 *** [do-build] Error code 1 /snip PostGIS is POSTGIS=1.5.3 GEOS=3.3.8-CAPI-1.7.8 PROJ=Rel. 4.8.0, 6 March 2012 LIBXML=2.7.8 USE_STATS (procs from 1.5 r5385 need upgrade) so apparently no raster support ... Is this a port issue or shall I report it to the GDAL crew? Frank -- Frank BRONIEWSKI METRICO s.à r.l. géomètres technologies d'information géographique rue des Romains 36 L-5433 NIEDERDONVEN tél.: +352 26 74 94 - 28 fax.: +352 26 74 94 99 http://www.metrico.lu ___ 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: FreeBSD Port: gdal-1.10.0
Thanks!! Your suggestion corrected my problem.
Ben Hacker Jr.
ITT Exelis Inc.
-Original Message-
From: Rainer Hurling [mailto:rhur...@gwdg.de]
Sent: Wednesday, August 28, 2013 12:42 AM
To: Hacker, Benjamin T - GS
Cc: 'sunp...@freebsd.org'; 'po...@freebsd.org'
Subject: Re: FreeBSD Port: gdal-1.10.0
Am 27.08.2013 23:31 (UTC+1) schrieb Hacker, Benjamin T - GS:
Dear Sir,
I have attempted to update my Installed Ports. I am having an issue with the
GDAL port as listed below. Any assistance you can provide would be greatly
appreciated!
Thanks!
{root@FreeBSD-OSM:/usr/ports/graphics/gdal # make install Enter
. . .
postgisrasterdataset.cpp: In function 'void GDALRegister_PostGISRaster()':
postgisrasterdataset.cpp:2052: error: 'GDAL_DMD_SUBDATASETS' was not
declared in this scope
gmake[2]: *** [../o/postgisrasterdataset.lo] Error 1
gmake[2]: Leaving directory
`/usr/ports/graphics/gdal/work/gdal-1.10.0/frmts/postgisraster'
gmake[1]: *** [postgisraster-install-obj] Error 2
gmake[1]: Leaving directory `/usr/ports/graphics/gdal/work/gdal-1.10.0/frmts'
gmake: *** [frmts-target] Error 2
*** [do-build] Error code 1
Stop in /usr/ports/graphics/gdal.
*** [install] Error code 1
Stop in /usr/ports/graphics/gdal.
root@FreeBSD-OSM:/usr/ports/graphics/gdal #}
{root@FreeBSD-OSM:/usr/ports/graphics/gdal # portupgrade -aR . . .
. . .
postgisrasterdataset.cpp: In function 'void GDALRegister_PostGISRaster()':
postgisrasterdataset.cpp:2052: error: 'GDAL_DMD_SUBDATASETS' was not
declared in this scope
gmake[2]: *** [../o/postgisrasterdataset.lo] Error 1
gmake[2]: Leaving directory
`/usr/ports/graphics/gdal/work/gdal-1.10.0/frmts/postgisraster'
gmake[1]: *** [postgisraster-install-obj] Error 2
gmake[1]: Leaving directory `/usr/ports/graphics/gdal/work/gdal-1.10.0/frmts'
gmake: *** [frmts-target] Error 2
*** [do-build] Error code 1
Stop in /usr/ports/graphics/gdal.
*** [build] Error code 1
Stop in /usr/ports/graphics/gdal.
** Command failed [exit code 1]: /usr/bin/script -qa
/tmp/portupgrade20130827-41511-2s1msu env UPGRADE_TOOL=portupgrade
UPGRADE_PORT=gdal-1.9.2 UPGRADE_PORT_VER=1.9.2 make
** Fix the problem and try again.
--- Skipping 'databases/postgis20' (postgis-2.0.2_1) because a
--- requisite package 'gdal-1.9.2' (graphics/gdal) failed (specify -k
--- to force)
** Listing the failed packages (-:ignored / *:skipped / !:failed)
! graphics/gdal (gdal-1.9.2)(unknown build error)
* databases/postgis20 (postgis-2.0.2_1) }
{root@FreeBSD-OSM:/usr/ports/graphics/gdal # uname -a
FreeBSD FreeBSD-OSM 9.1-RELEASE-p6 FreeBSD 9.1-RELEASE-p6 #0: Wed Aug 21
20:40:52 UTC 2013
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 }
{root@FreeBSD-OSM:/usr/ports/graphics/gdal # pkg_info
. . .
gdal-1.9.2 A translator library for geospatial data formats
. . .
root@FreeBSD-OSM:/usr/ports/graphics/gdal # }
Ben Hacker Jr.
ITT Exelis
Herndon, VA
For me this only happened, when an older graphics/gdal is installed.
There seems to be a problem not taking the new include/gdal.h from the port, if
an older /usr/local/include/gdal.h exists. So as a workaround deinstalling the
old port before building the new one should help.
HTH,
Rainer
sunpoet@ : After gdal-1.10.0 is committed now, could you please close my PR
180945, thanks.
This e-mail and any files transmitted with it may be proprietary and are
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this e-mail in error please notify the sender.
Please note that any views or opinions presented in this e-mail are solely
those of the author and do not necessarily represent those of Exelis Inc. The
recipient should check this e-mail and any attachments for the presence of
viruses. Exelis Inc. accepts no liability for any damage caused by any virus
transmitted by this e-mail.
___
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 Port: gdal-1.10.0
Dear Sir,
I have attempted to update my Installed Ports. I am having an issue with the
GDAL port as listed below. Any assistance you can provide would be greatly
appreciated!
Thanks!
{root@FreeBSD-OSM:/usr/ports/graphics/gdal # make install Enter
. . .
gmake[2]: Entering directory
`/usr/ports/graphics/gdal/work/gdal-1.10.0/frmts/png'
gmake[2]: Nothing to be done for `install-obj'.
gmake[2]: Leaving directory
`/usr/ports/graphics/gdal/work/gdal-1.10.0/frmts/png'
gmake -C pcraster install-obj
gmake[2]: Entering directory
`/usr/ports/graphics/gdal/work/gdal-1.10.0/frmts/pcraster'
gmake[2]: Nothing to be done for `install-obj'.
gmake[2]: Leaving directory
`/usr/ports/graphics/gdal/work/gdal-1.10.0/frmts/pcraster'
gmake -C rik install-obj
gmake[2]: Entering directory
`/usr/ports/graphics/gdal/work/gdal-1.10.0/frmts/rik'
gmake[2]: Nothing to be done for `install-obj'.
gmake[2]: Leaving directory
`/usr/ports/graphics/gdal/work/gdal-1.10.0/frmts/rik'
gmake -C ozi install-obj
gmake[2]: Entering directory
`/usr/ports/graphics/gdal/work/gdal-1.10.0/frmts/ozi'
gmake[2]: Nothing to be done for `install-obj'.
gmake[2]: Leaving directory
`/usr/ports/graphics/gdal/work/gdal-1.10.0/frmts/ozi'
gmake -C pdf install-obj
gmake[2]: Entering directory
`/usr/ports/graphics/gdal/work/gdal-1.10.0/frmts/pdf'
gmake[2]: Nothing to be done for `install-obj'.
gmake[2]: Leaving directory
`/usr/ports/graphics/gdal/work/gdal-1.10.0/frmts/pdf'
gmake -C postgisraster install-obj
gmake[2]: Entering directory
`/usr/ports/graphics/gdal/work/gdal-1.10.0/frmts/postgisraster'
/bin/sh /usr/local/bin/libtool --mode=compile --tag=CXX c++ -O2 -pipe -fPIC
-fno-strict-aliasing -DHAVE_SSE_AT_COMPILE_TIME -Wall -I ../mem -I ../vrt
-I/usr/local/include -I/usr/local/include/postgresql/server
-DPG_HAS_PQESCAPESTRINGCONN -I/usr/ports/graphics/gdal/work/gdal-1.10.0/port
-I/usr/ports/graphics/gdal/work/gdal-1.10.0/gcore
-I/usr/ports/graphics/gdal/work/gdal-1.10.0/alg
-I/usr/ports/graphics/gdal/work/gdal-1.10.0/ogr
-I/usr/ports/graphics/gdal/work/gdal-1.10.0/ogr/ogrsf_frmts -DOGR_ENABLED
-I/usr/local/include -I/usr/ports/graphics/gdal/work/gdal-1.10.0/port
-I/usr/local -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 -c -o
../o/postgisrasterdataset.lo postgisrasterdataset.cpp
libtool: compile: c++ -O2 -pipe -fPIC -fno-strict-aliasing
-DHAVE_SSE_AT_COMPILE_TIME -Wall -I ../mem -I ../vrt -I/usr/local/include
-I/usr/local/include/postgresql/server -DPG_HAS_PQESCAPESTRINGCONN
-I/usr/ports/graphics/gdal/work/gdal-1.10.0/port
-I/usr/ports/graphics/gdal/work/gdal-1.10.0/gcore
-I/usr/ports/graphics/gdal/work/gdal-1.10.0/alg
-I/usr/ports/graphics/gdal/work/gdal-1.10.0/ogr
-I/usr/ports/graphics/gdal/work/gdal-1.10.0/ogr/ogrsf_frmts -DOGR_ENABLED
-I/usr/local/include -I/usr/ports/graphics/gdal/work/gdal-1.10.0/port
-I/usr/local -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 -c
postgisrasterdataset.cpp -fPIC -DPIC -o ../o/.libs/postgisrasterdataset.o
postgisrasterdataset.cpp: In function 'void GDALRegister_PostGISRaster()':
postgisrasterdataset.cpp:2052: error: 'GDAL_DMD_SUBDATASETS' was not declared
in this scope
gmake[2]: *** [../o/postgisrasterdataset.lo] Error 1
gmake[2]: Leaving directory
`/usr/ports/graphics/gdal/work/gdal-1.10.0/frmts/postgisraster'
gmake[1]: *** [postgisraster-install-obj] Error 2
gmake[1]: Leaving directory `/usr/ports/graphics/gdal/work/gdal-1.10.0/frmts'
gmake: *** [frmts-target] Error 2
*** [do-build] Error code 1
Stop in /usr/ports/graphics/gdal.
*** [install] Error code 1
Stop in /usr/ports/graphics/gdal.
root@FreeBSD-OSM:/usr/ports/graphics/gdal #}
{root@FreeBSD-OSM:/usr/ports/graphics/gdal # portupgrade -aR
. . .
/bin/sh /usr/local/bin/libtool --mode=compile --tag=CXX c++ -O2 -pipe -fPIC
-fno-strict-aliasing -DHAVE_SSE_AT_COMPILE_TIME -Wall -I ../mem -I ../vrt
-I/usr/local/include -I/usr/local/include/postgresql/server
-DPG_HAS_PQESCAPESTRINGCONN -I/usr/ports/graphics/gdal/work/gdal-1.10.0/port
-I/usr/ports/graphics/gdal/work/gdal-1.10.0/gcore
-I/usr/ports/graphics/gdal/work/gdal-1.10.0/alg
-I/usr/ports/graphics/gdal/work/gdal-1.10.0/ogr
-I/usr/ports/graphics/gdal/work/gdal-1.10.0/ogr/ogrsf_frmts -DOGR_ENABLED
-I/usr/local/include -I/usr/ports/graphics/gdal/work/gdal-1.10.0/port
-I/usr/local -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 -c -o
../o/postgisrasterdataset.lo postgisrasterdataset.cpp
libtool: compile: c++ -O2 -pipe -fPIC -fno-strict-aliasing
-DHAVE_SSE_AT_COMPILE_TIME -Wall -I ../mem -I ../vrt -I/usr/local/include
-I/usr/local/include
Re: FreeBSD Port: gdal-1.10.0
Am 27.08.2013 23:31 (UTC+1) schrieb Hacker, Benjamin T - GS:
Dear Sir,
I have attempted to update my Installed Ports. I am having an issue with the
GDAL port as listed below. Any assistance you can provide would be greatly
appreciated!
Thanks!
{root@FreeBSD-OSM:/usr/ports/graphics/gdal # make install Enter
. . .
gmake[2]: Entering directory
`/usr/ports/graphics/gdal/work/gdal-1.10.0/frmts/png'
gmake[2]: Nothing to be done for `install-obj'.
gmake[2]: Leaving directory
`/usr/ports/graphics/gdal/work/gdal-1.10.0/frmts/png'
gmake -C pcraster install-obj
gmake[2]: Entering directory
`/usr/ports/graphics/gdal/work/gdal-1.10.0/frmts/pcraster'
gmake[2]: Nothing to be done for `install-obj'.
gmake[2]: Leaving directory
`/usr/ports/graphics/gdal/work/gdal-1.10.0/frmts/pcraster'
gmake -C rik install-obj
gmake[2]: Entering directory
`/usr/ports/graphics/gdal/work/gdal-1.10.0/frmts/rik'
gmake[2]: Nothing to be done for `install-obj'.
gmake[2]: Leaving directory
`/usr/ports/graphics/gdal/work/gdal-1.10.0/frmts/rik'
gmake -C ozi install-obj
gmake[2]: Entering directory
`/usr/ports/graphics/gdal/work/gdal-1.10.0/frmts/ozi'
gmake[2]: Nothing to be done for `install-obj'.
gmake[2]: Leaving directory
`/usr/ports/graphics/gdal/work/gdal-1.10.0/frmts/ozi'
gmake -C pdf install-obj
gmake[2]: Entering directory
`/usr/ports/graphics/gdal/work/gdal-1.10.0/frmts/pdf'
gmake[2]: Nothing to be done for `install-obj'.
gmake[2]: Leaving directory
`/usr/ports/graphics/gdal/work/gdal-1.10.0/frmts/pdf'
gmake -C postgisraster install-obj
gmake[2]: Entering directory
`/usr/ports/graphics/gdal/work/gdal-1.10.0/frmts/postgisraster'
/bin/sh /usr/local/bin/libtool --mode=compile --tag=CXX c++ -O2 -pipe -fPIC
-fno-strict-aliasing -DHAVE_SSE_AT_COMPILE_TIME -Wall -I ../mem -I ../vrt
-I/usr/local/include -I/usr/local/include/postgresql/server
-DPG_HAS_PQESCAPESTRINGCONN -I/usr/ports/graphics/gdal/work/gdal-1.10.0/port
-I/usr/ports/graphics/gdal/work/gdal-1.10.0/gcore
-I/usr/ports/graphics/gdal/work/gdal-1.10.0/alg
-I/usr/ports/graphics/gdal/work/gdal-1.10.0/ogr
-I/usr/ports/graphics/gdal/work/gdal-1.10.0/ogr/ogrsf_frmts -DOGR_ENABLED
-I/usr/local/include -I/usr/ports/graphics/gdal/work/gdal-1.10.0/port
-I/usr/local -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 -c -o
../o/postgisrasterdataset.lo postgisrasterdataset.cpp
libtool: compile: c++ -O2 -pipe -fPIC -fno-strict-aliasing
-DHAVE_SSE_AT_COMPILE_TIME -Wall -I ../mem -I ../vrt -I/usr/local/include
-I/usr/local/include/postgresql/server -DPG_HAS_PQESCAPESTRINGCONN
-I/usr/ports/graphics/gdal/work/gdal-1.10.0/port
-I/usr/ports/graphics/gdal/work/gdal-1.10.0/gcore
-I/usr/ports/graphics/gdal/work/gdal-1.10.0/alg
-I/usr/ports/graphics/gdal/work/gdal-1.10.0/ogr
-I/usr/ports/graphics/gdal/work/gdal-1.10.0/ogr/ogrsf_frmts -DOGR_ENABLED
-I/usr/local/include -I/usr/ports/graphics/gdal/work/gdal-1.10.0/port
-I/usr/local -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 -c
postgisrasterdataset.cpp -fPIC -DPIC -o ../o/.libs/postgisrasterdataset.o
postgisrasterdataset.cpp: In function 'void GDALRegister_PostGISRaster()':
postgisrasterdataset.cpp:2052: error: 'GDAL_DMD_SUBDATASETS' was not declared
in this scope
gmake[2]: *** [../o/postgisrasterdataset.lo] Error 1
gmake[2]: Leaving directory
`/usr/ports/graphics/gdal/work/gdal-1.10.0/frmts/postgisraster'
gmake[1]: *** [postgisraster-install-obj] Error 2
gmake[1]: Leaving directory `/usr/ports/graphics/gdal/work/gdal-1.10.0/frmts'
gmake: *** [frmts-target] Error 2
*** [do-build] Error code 1
Stop in /usr/ports/graphics/gdal.
*** [install] Error code 1
Stop in /usr/ports/graphics/gdal.
root@FreeBSD-OSM:/usr/ports/graphics/gdal #}
{root@FreeBSD-OSM:/usr/ports/graphics/gdal # portupgrade -aR
. . .
/bin/sh /usr/local/bin/libtool --mode=compile --tag=CXX c++ -O2 -pipe -fPIC
-fno-strict-aliasing -DHAVE_SSE_AT_COMPILE_TIME -Wall -I ../mem -I ../vrt
-I/usr/local/include -I/usr/local/include/postgresql/server
-DPG_HAS_PQESCAPESTRINGCONN -I/usr/ports/graphics/gdal/work/gdal-1.10.0/port
-I/usr/ports/graphics/gdal/work/gdal-1.10.0/gcore
-I/usr/ports/graphics/gdal/work/gdal-1.10.0/alg
-I/usr/ports/graphics/gdal/work/gdal-1.10.0/ogr
-I/usr/ports/graphics/gdal/work/gdal-1.10.0/ogr/ogrsf_frmts -DOGR_ENABLED
-I/usr/local/include -I/usr/ports/graphics/gdal/work/gdal-1.10.0/port
-I/usr/local -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 -c -o
../o/postgisrasterdataset.lo postgisrasterdataset.cpp
Re: [CFT] gdal 1.9.1 update and other changes
Hi, I got an error today while I tried to compile py-gdal in a jail where the ports dir is mounted as read-only. I don't know if that's really the reason for the compilation failure, but I can't think of anything else. The error is: make: don't know how to make sanity-config. Stop my /etc/make.conf: DISTDIR = /var/ports/distfiles PACKAGES = /var/ports/packages WRKDIRPREFIX = /tmp Unfortunately I am out of ideas, and google does not yield anything helpful for me, so I thought I mention this on the list here where are more skilled people than me hanging around ;-) I am glad to provide more info if necessary Frank Am 07.06.2012 05:30, schrieb Sunpoet Po-Chuan Hsieh: Hi, GDAL 1.9.1 was released several days ago. I'd like to make some changes along with this update [1]. The most important one is about the language bindings. I decide to move them to separate ports: - Perl binding: graphics/p5-Geo-GDAL [2] - Python binding: graphics/py-gdal [3] - PHP binding: graphics/php-gdal [4] - Ruby binding: graphics/ruby-gdal [5] The other changes to the Makefile include: - Update to 1.9.1 - Build with thread-safe support by default - Add lzma support - Adjust OPTIONS: - Add ICONV, KML and WEBP - Remove GRASS (cyclic dependency), PERL, PHP, PYTHON, RUBY and THREADS (default) - Add corresponding CONFIGURE_ARGS for disabled features - Cosmetic change Please test if it works for you. If I don't receive critical feedback, I plan to commit them this weekend or next Monday. Thanks! [1] http://people.freebsd.org/~sunpoet/gdal/gdal-1.9.1.patch [2] http://people.freebsd.org/~sunpoet/gdal/p5-Geo-GDAL.shar [3] http://people.freebsd.org/~sunpoet/gdal/php-gdal.shar [4] http://people.freebsd.org/~sunpoet/gdal/py-gdal.shar [5] http://people.freebsd.org/~sunpoet/gdal/ruby-gdal.shar Regards, sunpoet -- Frank BRONIEWSKI METRICO s.à r.l. géomètres technologies d'information géographique rue des Romains 36 L-5433 NIEDERDONVEN tél.: +352 26 74 94 - 28 fax.: +352 26 74 94 99 http://www.metrico.lu ___ 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
Re: [CFT] gdal 1.9.1 update and other changes
* Sunpoet Po-Chuan Hsieh (sunp...@freebsd.org) wrote: GDAL 1.9.1 was released several days ago. Please test if it works for you. If I don't receive critical feedback, I plan to commit them this weekend or next Monday. I don't use gdal directly so I can't really test it, but I've ran in in a tinderbox with different OPTIONS combinations. It's much better than 1.9.0, and fails only with WITHOUT_GEOTIFF: http://people.freebsd.org/~amdmi3/gdal-nogeotiff-1.9.1.log All bindings build fine. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ 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
On 8-6-2012 4:43, Sunpoet Hsieh wrote: On Thu, Jun 7, 2012 at 2:25 PM, Rainer Hurling rhur...@gwdg.de wrote: Am 07.06.2012 05:30 (UTC+1) schrieb Sunpoet Po-Chuan Hsieh: Hi, Many thanks for this update. What I observed so far: (1) graphics/gdal builds and installs fine. There is a minor problem: dependend port science/libkml (as option) does not configure, if devel/swig13 is installed. I'll check that again. I've tested it in tinderbox which does not have swig13 in the jail. (2) graphics/py-gdal asks for option NUMPY several times, even once more if it wants to install (after build). The port should be OK without numpy but the array support will not be enabled. I'm considering to turn NUMPY on by default or just change it from optional to required dependency. If this becomes required it means gcc46-fortran is pulled in. I wouldn't mind a default on option, but I think adding gcc46/fortran to an already complex tool chain should not be done if it can be avoided. Maybe the option description can be changed to: Enable array support through numPY This makes it easier for people to decide whether they need it. -- Mel ___ 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
Am 07.06.2012 05:30 (UTC+1) schrieb Sunpoet Po-Chuan Hsieh: Hi, Many thanks for this update. What I observed so far: (1) graphics/gdal builds and installs fine. There is a minor problem: dependend port science/libkml (as option) does not configure, if devel/swig13 is installed. (2) graphics/py-gdal asks for option NUMPY several times, even once more if it wants to install (after build). (3) graphics(p5-Geo-GDAL gives warnings about unrecognized arguments, but it does build and install: Building against GDAL defined in /usr/local/bin/gdal-config Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__OGR for Geo::OGR Writing MYMETA.yml Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__GDAL__Const for Geo::GDAL::Const Writing MYMETA.yml Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__OSR for Geo::OSR Writing MYMETA.yml Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__GDAL for Geo::GDAL Writing MYMETA.yml make -f Makefile_Geo__GDAL (4) graphics/ruby-gdal builds and installs fine, distinctive features. (5) graphics/php-gdal does not build with following messages: === Building for php-gdal-1.9.1 /usr/bin/sed -e '/^GDAL_ROOT/d' /usr/local/share/gdal/GDALmake.opt /usr/ports/graphics/php-gdal/work/gdal-1.9.1/swig/php/../../GDALmake.opt /bin/cp /usr/local/include/cpl_config.h /usr/ports/graphics/php-gdal/work/gdal-1.9.1/swig/php/../../port/ c++ -I../../port -I../../gcore -I../../alg -I../../ogr `php-config --includes` -O2 -pipe -O2 -fno-strict-aliasing -pipe -msse3 -I/usr/local/include -fPIC -c gdal_wrap.cpp gdal_wrap.cpp: In function 'void* SWIG_ZTS_ConvertResourcePtr(zval*, swig_type_info*, int)': gdal_wrap.cpp:935: error: invalid conversion from 'const char*' to 'char*' gmake: *** [gdal_wrap.o] Fehler 1 *** [do-build] Error code 1 Hope this helps, Rainer GDAL 1.9.1 was released several days ago. I'd like to make some changes along with this update [1]. The most important one is about the language bindings. I decide to move them to separate ports: - Perl binding: graphics/p5-Geo-GDAL [2] - Python binding: graphics/py-gdal [3] - PHP binding: graphics/php-gdal [4] - Ruby binding: graphics/ruby-gdal [5] The other changes to the Makefile include: - Update to 1.9.1 - Build with thread-safe support by default - Add lzma support - Adjust OPTIONS: - Add ICONV, KML and WEBP - Remove GRASS (cyclic dependency), PERL, PHP, PYTHON, RUBY and THREADS (default) - Add corresponding CONFIGURE_ARGS for disabled features - Cosmetic change Please test if it works for you. If I don't receive critical feedback, I plan to commit them this weekend or next Monday. Thanks! [1] http://people.freebsd.org/~sunpoet/gdal/gdal-1.9.1.patch [2] http://people.freebsd.org/~sunpoet/gdal/p5-Geo-GDAL.shar [3] http://people.freebsd.org/~sunpoet/gdal/php-gdal.shar [4] http://people.freebsd.org/~sunpoet/gdal/py-gdal.shar [5] http://people.freebsd.org/~sunpoet/gdal/ruby-gdal.shar 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: [CFT] gdal 1.9.1 update and other changes
Hi, I can confirm Rainers observation with swig13 and libkml, otherwise gdal builds and installs fine. Since I'm new to FreeBSD I still need to figure out what I need to do with those .shar files, so I can't give an update yet on the language packages Frank Am 07.06.2012 08:25, schrieb Rainer Hurling: Am 07.06.2012 05:30 (UTC+1) schrieb Sunpoet Po-Chuan Hsieh: Hi, Many thanks for this update. What I observed so far: (1) graphics/gdal builds and installs fine. There is a minor problem: dependend port science/libkml (as option) does not configure, if devel/swig13 is installed. (2) graphics/py-gdal asks for option NUMPY several times, even once more if it wants to install (after build). (3) graphics(p5-Geo-GDAL gives warnings about unrecognized arguments, but it does build and install: Building against GDAL defined in /usr/local/bin/gdal-config Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__OGR for Geo::OGR Writing MYMETA.yml Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__GDAL__Const for Geo::GDAL::Const Writing MYMETA.yml Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__OSR for Geo::OSR Writing MYMETA.yml Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__GDAL for Geo::GDAL Writing MYMETA.yml make -f Makefile_Geo__GDAL (4) graphics/ruby-gdal builds and installs fine, distinctive features. (5) graphics/php-gdal does not build with following messages: === Building for php-gdal-1.9.1 /usr/bin/sed -e '/^GDAL_ROOT/d' /usr/local/share/gdal/GDALmake.opt /usr/ports/graphics/php-gdal/work/gdal-1.9.1/swig/php/../../GDALmake.opt /bin/cp /usr/local/include/cpl_config.h /usr/ports/graphics/php-gdal/work/gdal-1.9.1/swig/php/../../port/ c++ -I../../port -I../../gcore -I../../alg -I../../ogr `php-config --includes` -O2 -pipe -O2 -fno-strict-aliasing -pipe -msse3 -I/usr/local/include -fPIC -c gdal_wrap.cpp gdal_wrap.cpp: In function 'void* SWIG_ZTS_ConvertResourcePtr(zval*, swig_type_info*, int)': gdal_wrap.cpp:935: error: invalid conversion from 'const char*' to 'char*' gmake: *** [gdal_wrap.o] Fehler 1 *** [do-build] Error code 1 Hope this helps, Rainer GDAL 1.9.1 was released several days ago. I'd like to make some changes along with this update [1]. The most important one is about the language bindings. I decide to move them to separate ports: - Perl binding: graphics/p5-Geo-GDAL [2] - Python binding: graphics/py-gdal [3] - PHP binding: graphics/php-gdal [4] - Ruby binding: graphics/ruby-gdal [5] The other changes to the Makefile include: - Update to 1.9.1 - Build with thread-safe support by default - Add lzma support - Adjust OPTIONS: - Add ICONV, KML and WEBP - Remove GRASS (cyclic dependency), PERL, PHP, PYTHON, RUBY and THREADS (default) - Add corresponding CONFIGURE_ARGS for disabled features - Cosmetic change Please test if it works for you. If I don't receive critical feedback, I plan to commit them this weekend or next Monday. Thanks! [1] http://people.freebsd.org/~sunpoet/gdal/gdal-1.9.1.patch [2] http://people.freebsd.org/~sunpoet/gdal/p5-Geo-GDAL.shar [3] http://people.freebsd.org/~sunpoet/gdal/php-gdal.shar [4] http://people.freebsd.org/~sunpoet/gdal/py-gdal.shar [5] http://people.freebsd.org/~sunpoet/gdal/ruby-gdal.shar 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 -- Frank BRONIEWSKI METRICO s.à r.l. géomètres technologies d'information géographique rue des Romains 36 L-5433 NIEDERDONVEN tél.: +352 26 74 94 - 28 fax.: +352 26 74 94 99 http://www.metrico.lu ___ 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
Am 07.06.2012 14:38 (UTC+1) schrieb Frank Broniewski: Hi, I can confirm Rainers observation with swig13 and libkml, otherwise gdal builds and installs fine. Since I'm new to FreeBSD I still need to figure out what I need to do with those .shar files, so I can't give an update yet on the language packages It seems with these .shar files you have to create their top directories manually. What I did (as root) is: cd /usr/ports mkdir graphics/p5-Geo-GDAL sh p5-Geo-GDAL.shar mkdir graphics/py-gdal sh py-gdal.shar mkdir graphics/php-gdal sh php-gdal.shar mkdir graphics/ruby-gdal sh ruby-gdal.shar After that the new ports are available. Frank Am 07.06.2012 08:25, schrieb Rainer Hurling: Am 07.06.2012 05:30 (UTC+1) schrieb Sunpoet Po-Chuan Hsieh: Hi, Many thanks for this update. What I observed so far: (1) graphics/gdal builds and installs fine. There is a minor problem: dependend port science/libkml (as option) does not configure, if devel/swig13 is installed. (2) graphics/py-gdal asks for option NUMPY several times, even once more if it wants to install (after build). (3) graphics(p5-Geo-GDAL gives warnings about unrecognized arguments, but it does build and install: Building against GDAL defined in /usr/local/bin/gdal-config Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__OGR for Geo::OGR Writing MYMETA.yml Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__GDAL__Const for Geo::GDAL::Const Writing MYMETA.yml Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__OSR for Geo::OSR Writing MYMETA.yml Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__GDAL for Geo::GDAL Writing MYMETA.yml make -f Makefile_Geo__GDAL (4) graphics/ruby-gdal builds and installs fine, distinctive features. (5) graphics/php-gdal does not build with following messages: === Building for php-gdal-1.9.1 /usr/bin/sed -e '/^GDAL_ROOT/d' /usr/local/share/gdal/GDALmake.opt /usr/ports/graphics/php-gdal/work/gdal-1.9.1/swig/php/../../GDALmake.opt /bin/cp /usr/local/include/cpl_config.h /usr/ports/graphics/php-gdal/work/gdal-1.9.1/swig/php/../../port/ c++ -I../../port -I../../gcore -I../../alg -I../../ogr `php-config --includes` -O2 -pipe -O2 -fno-strict-aliasing -pipe -msse3 -I/usr/local/include -fPIC -c gdal_wrap.cpp gdal_wrap.cpp: In function 'void* SWIG_ZTS_ConvertResourcePtr(zval*, swig_type_info*, int)': gdal_wrap.cpp:935: error: invalid conversion from 'const char*' to 'char*' gmake: *** [gdal_wrap.o] Fehler 1 *** [do-build] Error code 1 Hope this helps, Rainer GDAL 1.9.1 was released several days ago. I'd like to make some changes along with this update [1]. The most important one is about the language bindings. I decide to move them to separate ports: - Perl binding: graphics/p5-Geo-GDAL [2] - Python binding: graphics/py-gdal [3] - PHP binding: graphics/php-gdal [4] - Ruby binding: graphics/ruby-gdal [5] The other changes to the Makefile include: - Update to 1.9.1 - Build with thread-safe support by default - Add lzma support - Adjust OPTIONS: - Add ICONV, KML and WEBP - Remove GRASS (cyclic dependency), PERL, PHP, PYTHON, RUBY and THREADS (default) - Add corresponding CONFIGURE_ARGS for disabled features - Cosmetic change Please test if it works for you. If I don't receive critical feedback, I plan to commit them this weekend or next Monday. Thanks! [1] http://people.freebsd.org/~sunpoet/gdal/gdal-1.9.1.patch [2] http://people.freebsd.org/~sunpoet/gdal/p5-Geo-GDAL.shar [3] http://people.freebsd.org/~sunpoet/gdal/php-gdal.shar [4] http://people.freebsd.org/~sunpoet/gdal/py-gdal.shar [5] http://people.freebsd.org/~sunpoet/gdal/ruby-gdal.shar 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 ___ 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
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. (2) graphics/py-gdal asks for option NUMPY several times, even once more if it wants to install (after build). I can confirm this too ... I will test if the other languages compile asap. Btw, is it possible to compile more than one port at the same time? Or is this not advisable? Frank Am 07.06.2012 14:53, schrieb Rainer Hurling: Am 07.06.2012 14:38 (UTC+1) schrieb Frank Broniewski: Hi, I can confirm Rainers observation with swig13 and libkml, otherwise gdal builds and installs fine. Since I'm new to FreeBSD I still need to figure out what I need to do with those .shar files, so I can't give an update yet on the language packages It seems with these .shar files you have to create their top directories manually. What I did (as root) is: cd /usr/ports mkdir graphics/p5-Geo-GDAL sh p5-Geo-GDAL.shar mkdir graphics/py-gdal sh py-gdal.shar mkdir graphics/php-gdal sh php-gdal.shar mkdir graphics/ruby-gdal sh ruby-gdal.shar After that the new ports are available. Frank Am 07.06.2012 08:25, schrieb Rainer Hurling: Am 07.06.2012 05:30 (UTC+1) schrieb Sunpoet Po-Chuan Hsieh: Hi, Many thanks for this update. What I observed so far: (1) graphics/gdal builds and installs fine. There is a minor problem: dependend port science/libkml (as option) does not configure, if devel/swig13 is installed. (2) graphics/py-gdal asks for option NUMPY several times, even once more if it wants to install (after build). (3) graphics(p5-Geo-GDAL gives warnings about unrecognized arguments, but it does build and install: Building against GDAL defined in /usr/local/bin/gdal-config Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__OGR for Geo::OGR Writing MYMETA.yml Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__GDAL__Const for Geo::GDAL::Const Writing MYMETA.yml Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__OSR for Geo::OSR Writing MYMETA.yml Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__GDAL for Geo::GDAL Writing MYMETA.yml make -f Makefile_Geo__GDAL (4) graphics/ruby-gdal builds and installs fine, distinctive features. (5) graphics/php-gdal does not build with following messages: === Building for php-gdal-1.9.1 /usr/bin/sed -e '/^GDAL_ROOT/d' /usr/local/share/gdal/GDALmake.opt /usr/ports/graphics/php-gdal/work/gdal-1.9.1/swig/php/../../GDALmake.opt /bin/cp /usr/local/include/cpl_config.h /usr/ports/graphics/php-gdal/work/gdal-1.9.1/swig/php/../../port/ c++ -I../../port -I../../gcore -I../../alg -I../../ogr `php-config --includes` -O2 -pipe -O2 -fno-strict-aliasing -pipe -msse3 -I/usr/local/include -fPIC -c gdal_wrap.cpp gdal_wrap.cpp: In function 'void* SWIG_ZTS_ConvertResourcePtr(zval*, swig_type_info*, int)': gdal_wrap.cpp:935: error: invalid conversion from 'const char*' to 'char*' gmake: *** [gdal_wrap.o] Fehler 1 *** [do-build] Error code 1 Hope this helps, Rainer GDAL 1.9.1 was released several days ago. I'd like to make some changes along with this update [1]. The most important one is about the language bindings. I decide to move them to separate ports: - Perl binding: graphics/p5-Geo-GDAL [2] - Python binding: graphics/py-gdal [3] - PHP binding: graphics/php-gdal [4] - Ruby binding: graphics/ruby-gdal [5] The other changes to the Makefile include: - Update to 1.9.1 - Build with thread-safe support by default - Add lzma support - Adjust OPTIONS: - Add ICONV, KML and WEBP - Remove GRASS (cyclic dependency), PERL, PHP, PYTHON, RUBY and THREADS (default) - Add corresponding CONFIGURE_ARGS for disabled features - Cosmetic change Please test if it works for you. If I don't receive critical feedback, I plan to commit them this weekend or next Monday. Thanks! [1] http://people.freebsd.org/~sunpoet/gdal/gdal-1.9.1.patch [2] http://people.freebsd.org/~sunpoet/gdal/p5-Geo-GDAL.shar [3] http://people.freebsd.org/~sunpoet/gdal/php-gdal.shar [4] http://people.freebsd.org/~sunpoet/gdal/py-gdal.shar [5] http://people.freebsd.org/~sunpoet/gdal/ruby-gdal.shar 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 -- Frank BRONIEWSKI METRICO s.à r.l. géomètres technologies d'information géographique rue des Romains 36 L-5433 NIEDERDONVEN tél.: +352 26 74 94 - 28 fax.: +352 26 74 94 99 http://www.metrico.lu ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports
Re: [CFT] gdal 1.9.1 update and other changes
On Thu, Jun 7, 2012 at 2:25 PM, Rainer Hurling rhur...@gwdg.de wrote: Am 07.06.2012 05:30 (UTC+1) schrieb Sunpoet Po-Chuan Hsieh: Hi, Many thanks for this update. What I observed so far: (1) graphics/gdal builds and installs fine. There is a minor problem: dependend port science/libkml (as option) does not configure, if devel/swig13 is installed. I'll check that again. I've tested it in tinderbox which does not have swig13 in the jail. (2) graphics/py-gdal asks for option NUMPY several times, even once more if it wants to install (after build). The port should be OK without numpy but the array support will not be enabled. I'm considering to turn NUMPY on by default or just change it from optional to required dependency. (3) graphics(p5-Geo-GDAL gives warnings about unrecognized arguments, but it does build and install: Building against GDAL defined in /usr/local/bin/gdal-config Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__OGR for Geo::OGR Writing MYMETA.yml Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__GDAL__Const for Geo::GDAL::Const Writing MYMETA.yml Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__OSR for Geo::OSR Writing MYMETA.yml Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__GDAL for Geo::GDAL Writing MYMETA.yml make -f Makefile_Geo__GDAL (4) graphics/ruby-gdal builds and installs fine, distinctive features. (5) graphics/php-gdal does not build with following messages: === Building for php-gdal-1.9.1 /usr/bin/sed -e '/^GDAL_ROOT/d' /usr/local/share/gdal/GDALmake.opt /usr/ports/graphics/php-gdal/work/gdal-1.9.1/swig/php/../../GDALmake.opt /bin/cp /usr/local/include/cpl_config.h /usr/ports/graphics/php-gdal/work/gdal-1.9.1/swig/php/../../port/ c++ -I../../port -I../../gcore -I../../alg -I../../ogr `php-config --includes` -O2 -pipe -O2 -fno-strict-aliasing -pipe -msse3 -I/usr/local/include -fPIC -c gdal_wrap.cpp gdal_wrap.cpp: In function 'void* SWIG_ZTS_ConvertResourcePtr(zval*, swig_type_info*, int)': gdal_wrap.cpp:935: error: invalid conversion from 'const char*' to 'char*' gmake: *** [gdal_wrap.o] Fehler 1 *** [do-build] Error code 1 php-gdal does not build with php 5.4 (lang/php5). PHP_VER=53 in the old shar file indicates the ports framework to use php53 but php5 is not prohibited. I've updated the shar file. DEFAULT_PHP_VER=53 and IGNORE_WITH_PHP=5 should ensure not to use lang/php5. I haven't tested it with php52. Thanks for your test. :) Regards, sunpoet Hope this helps, Rainer GDAL 1.9.1 was released several days ago. I'd like to make some changes along with this update [1]. The most important one is about the language bindings. I decide to move them to separate ports: - Perl binding: graphics/p5-Geo-GDAL [2] - Python binding: graphics/py-gdal [3] - PHP binding: graphics/php-gdal [4] - Ruby binding: graphics/ruby-gdal [5] The other changes to the Makefile include: - Update to 1.9.1 - Build with thread-safe support by default - Add lzma support - Adjust OPTIONS: - Add ICONV, KML and WEBP - Remove GRASS (cyclic dependency), PERL, PHP, PYTHON, RUBY and THREADS (default) - Add corresponding CONFIGURE_ARGS for disabled features - Cosmetic change Please test if it works for you. If I don't receive critical feedback, I plan to commit them this weekend or next Monday. Thanks! [1] http://people.freebsd.org/~sunpoet/gdal/gdal-1.9.1.patch [2] http://people.freebsd.org/~sunpoet/gdal/p5-Geo-GDAL.shar [3] http://people.freebsd.org/~sunpoet/gdal/php-gdal.shar [4] http://people.freebsd.org/~sunpoet/gdal/py-gdal.shar [5] http://people.freebsd.org/~sunpoet/gdal/ruby-gdal.shar Regards, sunpoet -- Sunpoet Po-Chuan Hsieh sunpoet at sunpoet.net sunpoet at FreeBSD.org 4096R/CC57E36B 8AD8 68F2 7D2B 0A10 7E9B 8CC0 DC44 247E CC57 E36B http://people.FreeBSD.org/~sunpoet/pgpkeys.txt ___ 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
[CFT] gdal 1.9.1 update and other changes
Hi, GDAL 1.9.1 was released several days ago. I'd like to make some changes along with this update [1]. The most important one is about the language bindings. I decide to move them to separate ports: - Perl binding: graphics/p5-Geo-GDAL [2] - Python binding: graphics/py-gdal [3] - PHP binding: graphics/php-gdal [4] - Ruby binding: graphics/ruby-gdal [5] The other changes to the Makefile include: - Update to 1.9.1 - Build with thread-safe support by default - Add lzma support - Adjust OPTIONS: - Add ICONV, KML and WEBP - Remove GRASS (cyclic dependency), PERL, PHP, PYTHON, RUBY and THREADS (default) - Add corresponding CONFIGURE_ARGS for disabled features - Cosmetic change Please test if it works for you. If I don't receive critical feedback, I plan to commit them this weekend or next Monday. Thanks! [1] http://people.freebsd.org/~sunpoet/gdal/gdal-1.9.1.patch [2] http://people.freebsd.org/~sunpoet/gdal/p5-Geo-GDAL.shar [3] http://people.freebsd.org/~sunpoet/gdal/php-gdal.shar [4] http://people.freebsd.org/~sunpoet/gdal/py-gdal.shar [5] http://people.freebsd.org/~sunpoet/gdal/ruby-gdal.shar Regards, sunpoet -- Sunpoet Po-Chuan Hsieh sunpoet at sunpoet.net sunpoet at FreeBSD.org 4096R/CC57E36B 8AD8 68F2 7D2B 0A10 7E9B 8CC0 DC44 247E CC57 E36B http://people.FreeBSD.org/~sunpoet/pgpkeys.txt ___ 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 is broken again
After big update session from weekend, when trying to build graphics/gdal, I get the following messages: [...] gmake[2]: Entering directory `/usr/ports/graphics/gdal/work/gdal-1.9.0/frmts/gif' /bin/sh /usr/local/bin/libtool --mode=compile --tag=CXX c++ -O2 -pipe -O2 -fno-strict-aliasing -pipe -msse3 -Wall -I/usr/ports/graphics/gdal/work/gdal-1.9.0/port -I/usr/ports/graphics/gdal/work/gdal-1.9.0/gcore -I/usr/ports/graphics/gdal/work/gdal-1.9.0/alg -I/usr/ports/graphics/gdal/work/gdal-1.9.0/ogr -I/usr/ports/graphics/gdal/work/gdal-1.9.0/ogr/ogrsf_frmts -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 -c -o ../o/gifdataset.lo gifdataset.cpp libtool: compile: c++ -O2 -pipe -O2 -fno-strict-aliasing -pipe -msse3 -Wall -I/usr/ports/graphics/gdal/work/gdal-1.9.0/port -I/usr/ports/graphics/gdal/work/gdal-1.9.0/gcore -I/usr/ports/graphics/gdal/work/gdal-1.9.0/alg -I/usr/ports/graphics/gdal/work/gdal-1.9.0/ogr -I/usr/ports/graphics/gdal/work/gdal-1.9.0/ogr/ogrsf_frmts -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 -c gifdataset.cpp -fPIC -DPIC -o ../o/.libs/gifdataset.o gifdataset.cpp: In static member function 'static GDALDataset* GIFDataset::CreateCopy(const char*, GDALDataset*, int, char**, int (*)(double, const char*, void*), void*)': gifdataset.cpp:599: error: 'PrintGifError' was not declared in this scope gifdataset.cpp:625: error: 'PrintGifError' was not declared in this scope gmake[2]: *** [../o/gifdataset.lo] Fehler 1 gmake[2]: Leaving directory `/usr/ports/graphics/gdal/work/gdal-1.9.0/frmts/gif' gmake[1]: *** [gif-install-obj] Fehler 2 gmake[1]: Leaving directory `/usr/ports/graphics/gdal/work/gdal-1.9.0/frmts' gmake: *** [frmts-target] Fehler 2 *** [do-build] Error code 1 This also happens on pointyhat, eg: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.7.20120603171103/gdal-1.9.0_1.log Could this be related to the update of graphics/giflib? Thanks for any help, Rainer Hurling ___ 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 is broken again
On 04.06.2012 16:47 (UTC+2), Rainer Hurling wrote:
After big update session from weekend, when trying to build
graphics/gdal, I get the following messages:
[...]
gmake[2]: Entering directory
`/usr/ports/graphics/gdal/work/gdal-1.9.0/frmts/gif'
/bin/sh /usr/local/bin/libtool --mode=compile --tag=CXX c++ -O2 -pipe
-O2 -fno-strict-aliasing -pipe -msse3 -Wall
-I/usr/ports/graphics/gdal/work/gdal-1.9.0/port
-I/usr/ports/graphics/gdal/work/gdal-1.9.0/gcore
-I/usr/ports/graphics/gdal/work/gdal-1.9.0/alg
-I/usr/ports/graphics/gdal/work/gdal-1.9.0/ogr
-I/usr/ports/graphics/gdal/work/gdal-1.9.0/ogr/ogrsf_frmts -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 -c -o
../o/gifdataset.lo gifdataset.cpp
libtool: compile: c++ -O2 -pipe -O2 -fno-strict-aliasing -pipe -msse3
-Wall -I/usr/ports/graphics/gdal/work/gdal-1.9.0/port
-I/usr/ports/graphics/gdal/work/gdal-1.9.0/gcore
-I/usr/ports/graphics/gdal/work/gdal-1.9.0/alg
-I/usr/ports/graphics/gdal/work/gdal-1.9.0/ogr
-I/usr/ports/graphics/gdal/work/gdal-1.9.0/ogr/ogrsf_frmts -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 -c
gifdataset.cpp -fPIC -DPIC -o ../o/.libs/gifdataset.o
gifdataset.cpp: In static member function 'static GDALDataset*
GIFDataset::CreateCopy(const char*, GDALDataset*, int, char**, int
(*)(double, const char*, void*), void*)':
gifdataset.cpp:599: error: 'PrintGifError' was not declared in this scope
gifdataset.cpp:625: error: 'PrintGifError' was not declared in this scope
gmake[2]: *** [../o/gifdataset.lo] Fehler 1
gmake[2]: Leaving directory
`/usr/ports/graphics/gdal/work/gdal-1.9.0/frmts/gif'
gmake[1]: *** [gif-install-obj] Fehler 2
gmake[1]: Leaving directory
`/usr/ports/graphics/gdal/work/gdal-1.9.0/frmts'
gmake: *** [frmts-target] Fehler 2
*** [do-build] Error code 1
This also happens on pointyhat, eg:
http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.7.20120603171103/gdal-1.9.0_1.log
Could this be related to the update of graphics/giflib?
Sorry for answering myself. I just found that it is fixed upstream for
existing 1.9 branches and upcoming gdal 1.9.2 (trunk), see
http://trac.osgeo.org/gdal/ticket/4675
I attached a patch for our ports version 1.9.0, which should solve this
issue.
Thanks for any help,
Rainer Hurling
--- frmts/gif/gifdataset.cpp.orig 2012-01-04 08:03:28.0 +0100
+++ frmts/gif/gifdataset.cpp2012-06-04 17:21:24.0 +0200
@@ -470,6 +470,28 @@
}
//
+/*GDALPrintGifError() */
+//
+
+static void GDALPrintGifError(const char* pszMsg)
+{
+/* GIFLIB_MAJOR is only defined in libgif = 4.2.0 */
+/* libgif 4.2.0 has retired PrintGifError() and added GifErrorString() */
+#if defined(GIFLIB_MAJOR) defined(GIFLIB_MINOR) \
+((GIFLIB_MAJOR == 4 GIFLIB_MINOR = 2) || GIFLIB_MAJOR 4)
+/* Static string actually, hence the const char* cast */
+const char* pszGIFLIBError = (const char*) GifErrorString();
+if (pszGIFLIBError == NULL)
+pszGIFLIBError = Unknown error;
+CPLError( CE_Failure, CPLE_AppDefined,
+ %s. GIFLib Error : %s, pszMsg, pszGIFLIBError );
+#else
+PrintGifError();
+CPLError( CE_Failure, CPLE_AppDefined, %s, pszMsg );
+#endif
+}
+
+//
/* CreateCopy() */
//
@@ -596,9 +618,7 @@
psGifCT-ColorCount, 255, psGifCT) == GIF_ERROR)
{
FreeMapObject(psGifCT);
-PrintGifError();
-CPLError( CE_Failure, CPLE_AppDefined,
- Error writing gif file. );
+GDALPrintGifError(Error writing gif file.);
EGifCloseFile(hGifFile);
VSIFCloseL( fp );
return NULL;
@@ -622,9 +642,7 @@
if (EGifPutImageDesc(hGifFile, 0, 0, nXSize, nYSize, bInterlace, NULL) ==
GIF_ERROR )
{
-PrintGifError();
-CPLError( CE_Failure, CPLE_AppDefined,
- Error writing gif file. );
+GDALPrintGifError(Error writing gif file.);
EGifCloseFile(hGifFile);
VSIFCloseL( fp );
return NULL;
___
freebsd-ports
graphics/gdal: gifdataset.cpp:599:23: error: 'PrintGifError' was not declared in this scope
Since the last port update, I get this sticky error in gdal: libtool: compile: g++46 -O3 -pipe -fno-strict-aliasing -march=native -Wl,-rpath=/usr/local/lib/gcc46 -Wall -I/usr/ports/graphics/gdal/work/gdal-1.9.0/port -I/usr/ports/graphics/gdal/work/gdal-1.9.0/gcore -I/usr/ports/graphics/gdal/work/gdal-1.9.0/alg -I/usr/ports/graphics/gdal/work/gdal-1.9.0/ogr -I/usr/ports/graphics/gdal/work/gdal-1.9.0/ogr/ogrsf_frmts -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 -I/usr/local/include -I/usr/local -I/usr/local/include -I/usr -I/usr/include -c gifdataset.cpp -fPIC -DPIC -o ../o/.libs/gifdataset.o gifdataset.cpp: In static member function 'static GDALDataset* GIFDataset::CreateCopy(const char*, GDALDataset*, int, char**, GDALProgressFunc, void*)': gifdataset.cpp:599:23: error: 'PrintGifError' was not declared in this scope gifdataset.cpp:625:23: error: 'PrintGifError' was not declared in this scope gmake[2]: *** [../o/gifdataset.lo] Error 1 gmake[2]: Leaving directory `/usr/ports/graphics/gdal/work/gdal-1.9.0/frmts/gif' gmake[1]: *** [gif-install-obj] Error 2 gmake[1]: Leaving directory `/usr/ports/graphics/gdal/work/gdal-1.9.0/frmts' gmake: *** [frmts-target] Error 2 *** [do-build] Error code 1 Stop in /usr/ports/graphics/gdal. *** [build] Error code 1 Stop in /usr/ports/graphics/gdal. === make failed for graphics/gdal === Aborting update Terminated === You can restart from the point of failure with this command line: portmaster flags graphics/gdal Regards, Oliver signature.asc Description: OpenPGP digital signature
Re: graphics/gdal: gifdataset.cpp:599:23: error: 'PrintGifError' was not declared in this scope
Hi! Since the last port update, I get this sticky error in gdal: It's in graphics/giflib, the latest update to 4.2.0 dropped the symbol PrintGifError. All the dependent packages need to be recompiled 8-( Yes, I know. This is messy. libtool: compile: g++46 -O3 -pipe -fno-strict-aliasing -march=native -Wl,-rpath=/usr/local/lib/gcc46 -Wall -I/usr/ports/graphics/gdal/work/gdal-1.9.0/port -I/usr/ports/graphics/gdal/work/gdal-1.9.0/gcore -I/usr/ports/graphics/gdal/work/gdal-1.9.0/alg -I/usr/ports/graphics/gdal/work/gdal-1.9.0/ogr -I/usr/ports/graphics/gdal/work/gdal-1.9.0/ogr/ogrsf_frmts -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 -I/usr/local/include -I/usr/local -I/usr/local/include -I/usr -I/usr/include -c gifdataset.cpp -fPIC -DPIC -o ../o/.libs/gifdataset.o gifdataset.cpp: In static member function 'static GDALDataset* GIFDataset::CreateCopy(const char*, GDALDataset*, int, char**, GDALProgressFunc, void*)': gifdataset.cpp:599:23: error: 'PrintGifError' was not declared in this scope gifdataset.cpp:625:23: error: 'PrintGifError' was not declared in this scope gmake[2]: *** [../o/gifdataset.lo] Error 1 gmake[2]: Leaving directory `/usr/ports/graphics/gdal/work/gdal-1.9.0/frmts/gif' gmake[1]: *** [gif-install-obj] Error 2 gmake[1]: Leaving directory `/usr/ports/graphics/gdal/work/gdal-1.9.0/frmts' gmake: *** [frmts-target] Error 2 *** [do-build] Error code 1 Stop in /usr/ports/graphics/gdal. *** [build] Error code 1 Stop in /usr/ports/graphics/gdal. === make failed for graphics/gdal === Aborting update Terminated === You can restart from the point of failure with this command line: portmaster flags graphics/gdal Regards, Oliver -- p...@opsec.eu+49 171 3101372 8 years to go ! ___ 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)
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
X%%DATADIR
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
-I/usr/local
Re: giflib in graphics/gdal
On 2012-Feb-21 14:51:50 -0500, Steve Wills swi...@freebsd.org wrote: Is it correct to use portmaster -o graphics/giflib graphics/libungif Looks OK to me. And then rebuild all ports that used libungif. And thew next question is I have in /var/db/pgs bot giflib and libingif. How can I find whic one is installed, please? Or are both? They install files to the same place, overwriting each other. So whichever one was installed last would be the one that's really installed. It's not quite that simple. Both install include/gif_lib.h but the associated libraries have different names. If you have both installed, the most most recently installed will select which include/gif_lib.h is used but the library used will depend on the whims of the port's configuration tools. is they're very similar, so it didn't cause problems. Nevertheless, it's still a bad idea for them both to be installed, hence the addition of the conflict between them. It's very unfortunate that the ports depending on libungif weren't all cleaned up before the conflict was added. The current situation is a mess and, for many people, requires manual intervention to make the ports system work. -- Peter Jeremy pgpEnRSvwJ7MB.pgp Description: PGP signature
Re: giflib in graphics/gdal
On 22.02.2012 22:27 (UTC+1), Peter Jeremy wrote: On 2012-Feb-21 14:51:50 -0500, Steve Willsswi...@freebsd.org wrote: Is it correct to use portmaster -o graphics/giflib graphics/libungif Looks OK to me. And then rebuild all ports that used libungif. And thew next question is I have in /var/db/pgs bot giflib and libingif. How can I find whic one is installed, please? Or are both? They install files to the same place, overwriting each other. So whichever one was installed last would be the one that's really installed. It's not quite that simple. Both install include/gif_lib.h but the associated libraries have different names. If you have both installed, the most most recently installed will select which include/gif_lib.h is used but the library used will depend on the whims of the port's configuration tools. is they're very similar, so it didn't cause problems. Nevertheless, it's still a bad idea for them both to be installed, hence the addition of the conflict between them. It's very unfortunate that the ports depending on libungif weren't all cleaned up before the conflict was added. The current situation is a mess and, for many people, requires manual intervention to make the ports system work. Yes, for example graphics/osg is another candidate ... ___ 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: giflib in graphics/gdal
On Wednesday 22 February 2012 15:27:09 Peter Jeremy wrote: On 2012-Feb-21 14:51:50 -0500, Steve Wills swi...@freebsd.org wrote: Is it correct to use portmaster -o graphics/giflib graphics/libungif Looks OK to me. And then rebuild all ports that used libungif. And thew next question is I have in /var/db/pgs bot giflib and libingif. How can I find whic one is installed, please? Or are both? They install files to the same place, overwriting each other. So whichever one was installed last would be the one that's really installed. It's not quite that simple. Both install include/gif_lib.h but the associated libraries have different names. If you have both installed, the most most recently installed will select which include/gif_lib.h is used but the library used will depend on the whims of the port's configuration tools. is they're very similar, so it didn't cause problems. Nevertheless, it's still a bad idea for them both to be installed, hence the addition of the conflict between them. It's very unfortunate that the ports depending on libungif weren't all cleaned up before the conflict was added. The current situation is a mess and, for many people, requires manual intervention to make the ports system work. I did use portmaster -o and looks like it works for now without problems... Mitja http://jpgmag.com/people/lumiwa ___ 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: giflib in graphics/gdal
On 22.02.2012 22:37 (UTC+1), Rainer Hurling wrote: On 22.02.2012 22:27 (UTC+1), Peter Jeremy wrote: On 2012-Feb-21 14:51:50 -0500, Steve Willsswi...@freebsd.org wrote: Is it correct to use portmaster -o graphics/giflib graphics/libungif Looks OK to me. And then rebuild all ports that used libungif. And thew next question is I have in /var/db/pgs bot giflib and libingif. How can I find whic one is installed, please? Or are both? They install files to the same place, overwriting each other. So whichever one was installed last would be the one that's really installed. It's not quite that simple. Both install include/gif_lib.h but the associated libraries have different names. If you have both installed, the most most recently installed will select which include/gif_lib.h is used but the library used will depend on the whims of the port's configuration tools. is they're very similar, so it didn't cause problems. Nevertheless, it's still a bad idea for them both to be installed, hence the addition of the conflict between them. It's very unfortunate that the ports depending on libungif weren't all cleaned up before the conflict was added. The current situation is a mess and, for many people, requires manual intervention to make the ports system work. Yes, for example graphics/osg is another candidate ... Oops, just recognized, that there is already PR ports/165370 and ports/165372 for it. Sorry for the noise. ___ 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: giflib in graphics/gdal
On Tue, 21 Feb 2012 08:39:38 +0100
Rainer Hurling articulated:
Dear list,
after changing from graphics/ungif to graphics/giflib there is a
problem with building graphics/gdal. Because other ports depending on
it, this should be corrected as soon as possible, I think.
The patch could be something like this:
--- Makefile.orig 2012-02-08 07:52:24.0 +0100
+++ Makefile2012-02-21 08:34:04.0 +0100
@@ -104,7 +104,7 @@
.endif
.if !defined(WITHOUT_GIF)
-LIB_DEPENDS+= ungif.5:${PORTSDIR}/graphics/libungif
+LIB_DEPENDS+= gif.5:${PORTSDIR}/graphics/giflib
CONFIGURE_ARGS+= --with-gif=${LOCALBASE}
.endif
@@ -276,9 +276,6 @@
.endif
post-patch:
-.if !defined(WITHOUT_GIF)
- @${REINPLACE_CMD} -e 's|lgif|lungif|' ${WRKSRC}/configure
-.endif
.if defined(WITH_PYTHON)
@${REINPLACE_CMD} -e '\
s,%%MAKE_ENV%%,${MAKE_ENV},; \
Did you contact the port maintainer: sunp...@freebsd.org as well as
possibly submitting a PR against the port? If not, it might prove
useful.
--
Jerry ♔
Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the Reply-To header.
__
___
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: giflib in graphics/gdal
Am 21.02.2012 14:40 (UTC+1) schrieb Jerry:
On Tue, 21 Feb 2012 08:39:38 +0100
Rainer Hurling articulated:
Dear list,
after changing from graphics/ungif to graphics/giflib there is a
problem with building graphics/gdal. Because other ports depending on
it, this should be corrected as soon as possible, I think.
The patch could be something like this:
--- Makefile.orig 2012-02-08 07:52:24.0 +0100
+++ Makefile2012-02-21 08:34:04.0 +0100
@@ -104,7 +104,7 @@
.endif
.if !defined(WITHOUT_GIF)
-LIB_DEPENDS+= ungif.5:${PORTSDIR}/graphics/libungif
+LIB_DEPENDS+= gif.5:${PORTSDIR}/graphics/giflib
CONFIGURE_ARGS+= --with-gif=${LOCALBASE}
.endif
@@ -276,9 +276,6 @@
.endif
post-patch:
-.if !defined(WITHOUT_GIF)
- @${REINPLACE_CMD} -e 's|lgif|lungif|' ${WRKSRC}/configure
-.endif
.if defined(WITH_PYTHON)
@${REINPLACE_CMD} -e '\
s,%%MAKE_ENV%%,${MAKE_ENV},; \
Did you contact the port maintainer: sunp...@freebsd.org as well as
possibly submitting a PR against the port? If not, it might prove
useful.
As you can see in CC of the original posting he should get a copy.
I did not file a PR because I thought this should be corrected as soon
as possible. But perhaps this was not the best way ...
___
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: giflib in graphics/gdal
I saw new gdal in ports...
My question is: in the /usr/ports/UPDATING is first uninstall libungif and
than install giflib and reinstall all ports.
Is it correct to use portmaster -o graphics/giflib graphics/libungif
And thew next question is I have in /var/db/pgs bot giflib and libingif.
How can I find whic one is installed, please? Or are both?
Thanks in advance.
On Tue, Feb 21, 2012 at 7:40 AM, Jerry je...@seibercom.net wrote:
On Tue, 21 Feb 2012 08:39:38 +0100
Rainer Hurling articulated:
Dear list,
after changing from graphics/ungif to graphics/giflib there is a
problem with building graphics/gdal. Because other ports depending on
it, this should be corrected as soon as possible, I think.
The patch could be something like this:
--- Makefile.orig 2012-02-08 07:52:24.0 +0100
+++ Makefile2012-02-21 08:34:04.0 +0100
@@ -104,7 +104,7 @@
.endif
.if !defined(WITHOUT_GIF)
-LIB_DEPENDS+= ungif.5:${PORTSDIR}/graphics/libungif
+LIB_DEPENDS+= gif.5:${PORTSDIR}/graphics/giflib
CONFIGURE_ARGS+= --with-gif=${LOCALBASE}
.endif
@@ -276,9 +276,6 @@
.endif
post-patch:
-.if !defined(WITHOUT_GIF)
- @${REINPLACE_CMD} -e 's|lgif|lungif|' ${WRKSRC}/configure
-.endif
.if defined(WITH_PYTHON)
@${REINPLACE_CMD} -e '\
s,%%MAKE_ENV%%,${MAKE_ENV},; \
Did you contact the port maintainer: sunp...@freebsd.org as well as
possibly submitting a PR against the port? If not, it might prove
useful.
--
Jerry ♔
Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the Reply-To header.
__
___
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: giflib in graphics/gdal
I saw new gdal in ports... Yes, the graphics/gdal port was updated to use giflib. My question is: in the /usr/ports/UPDATING is first uninstall libungif and than install giflib and reinstall all ports. Is it correct to use portmaster -o graphics/giflib graphics/libungif Looks OK to me. And thew next question is I have in /var/db/pgs bot giflib and libingif. How can I find whic one is installed, please? Or are both? They install files to the same place, overwriting each other. So whichever one was installed last would be the one that's really installed. This is the reason for the addition of the conflict between the two. The good news is they're very similar, so it didn't cause problems. Nevertheless, it's still a bad idea for them both to be installed, hence the addition of the conflict between them. Steve ___ 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
giflib in graphics/gdal
Dear list,
after changing from graphics/ungif to graphics/giflib there is a problem
with building graphics/gdal. Because other ports depending on it, this
should be corrected as soon as possible, I think.
The patch could be something like this:
--- Makefile.orig 2012-02-08 07:52:24.0 +0100
+++ Makefile2012-02-21 08:34:04.0 +0100
@@ -104,7 +104,7 @@
.endif
.if !defined(WITHOUT_GIF)
-LIB_DEPENDS+= ungif.5:${PORTSDIR}/graphics/libungif
+LIB_DEPENDS+= gif.5:${PORTSDIR}/graphics/giflib
CONFIGURE_ARGS+= --with-gif=${LOCALBASE}
.endif
@@ -276,9 +276,6 @@
.endif
post-patch:
-.if !defined(WITHOUT_GIF)
- @${REINPLACE_CMD} -e 's|lgif|lungif|' ${WRKSRC}/configure
-.endif
.if defined(WITH_PYTHON)
@${REINPLACE_CMD} -e '\
s,%%MAKE_ENV%%,${MAKE_ENV},; \
Rainer Hurling
___
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: [Update] Gdal 1.8.1 - 1.9.0
coder.tuxfamily wrote on 13.01.2012 23:02: Hi, There is a new version of Gdal (graphics/gdal) 1.9.0. Here the diff, seems works but don't have time to make all tests. best regards 1. the diff is inverted. 2. this port has it's maintainer 3. please submit corrected patch as GNATS PR -- Regards, Ruslan Tinderboxing kills... the drives. ___ 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: [Update] Gdal 1.8.1 - 1.9.0
coder.tuxfamily co...@tuxfamily.org writes:
There is a new version of Gdal (graphics/gdal) 1.9.0.
Here the diff, seems works but don't have time to make all tests.
[...]
@@ -17,7 +16,7 @@
COMMENT= A translator library for geospatial data formats
CONFIGURE_ARGS= --datadir=${DATADIR} --with-libz=/usr
-CONFIGURE_ENV= LDFLAGS=${LDFLAGS}
+CONFIGURE_ENV= LDFLAGS+=${LDFLAGS}
GNU_CONFIGURE= yes
LDFLAGS+=-L${LOCALBASE}
MAKEFILE=GNUmakefile
Passing LDFLAGS seems redundant since ports/157936. The line was added
just a day before the sweeping removal.
___
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 version 1.7.2
On 19.07.2010 11:51 (UTC+1), Rainer Hurling wrote: gdal version 1.7.2 was released on April, 23th. There are many improvements against version 1.6.0 (from December 2008) which we found in the ports. Are there any plans to update graphics/gdal in the next time? Thanks for updating :-) Rainer Hurling ___ 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 version 1.7.2
Because of getting no response on the first posting until now, I tried
to make a suggestion for a patch. Sorry for answering to myself.
On 19.07.2010 11:51 (UTC+1), Rainer Hurling wrote:
gdal version 1.7.2 was released on April, 23th. There are many
improvements against version 1.6.0 (from December 2008) which we found
in the ports.
Are there any plans to update graphics/gdal in the next time?
The attached patch upgrades graphics/gdal from 1.6.0 to 1.7.2. Building
and installing works for me and new features of gdal like converting R
and SAGA GIS datasets are working :-)
As I have mentioned in another posting, there is a problem with option
'python'. When option 'python' is checked ON, the PORTREVISION will be
hardcoded to 4, see line 192 of original Makefile (instead of 9 for the
most recent version from today). I changed PORTREVISION to
PYDISTUTILS_PORTREVISION, but I am not sure, if this is the right way ;-(
The patch increments libgdal version from lgdal.14 to lgdal.15. Due to
this some other ports like math/saga should also be updated.
Could someone please be so kind to have a look at this patch? An updated
graphics/gdal port is really needed for other ports like math/R and
math/saga.
If I could help (like testing) in some way please let me know.
Thanks in advance,
Rainer Hurling
diff -Naur gdal_1.6.0/Makefile gdal/Makefile
--- gdal_1.6.0/Makefile 2010-07-26 16:34:40.0 +0200
+++ gdal/Makefile 2010-08-01 09:32:29.0 +0200
@@ -6,10 +6,10 @@
#
PORTNAME= gdal
-PORTVERSION= 1.6.0
-PORTREVISION= 9
+PORTVERSION= 1.7.2
CATEGORIES=graphics geography
-MASTER_SITES= ftp://ftp.remotesensing.org/pub/gdal/ \
+MASTER_SITES= http://download.osgeo.org/gdal/ \
+ ftp://ftp.remotesensing.org/pub/gdal/ \
http://www.gdal.org/dl/ \
http://dl.maptools.org/dl/gdal/ \
http://sunpoet.net/distfiles/
@@ -189,7 +189,7 @@
PYEASYINSTALL_CMD= ${LOCALBASE}/bin/easy_install-${PYTHON_VER}
PYDISTUTILS_PKGNAME= ${PORTNAME:U}
PYDISTUTILS_PKGVERSION=${PORTVERSION}
-PORTREVISION= 4
+PYDISTUTILS_PORTREVISION= 4
_OSRELEASE!= ${UNAME} -r
PYEASYINSTALL_OSARCH= -${OPSYS:L}-${_OSRELEASE}-${ARCH}
PYEASYINSTALL_EGG=
${PYDISTUTILS_PKGNAME:C/[^A-Za-z0-9.]+/_/g}-${PYDISTUTILS_PKGVERSION:C/[^A-Za-z0-9.]+/_/g}-${PYTHON_VERSION:S/thon//}${PYEASYINSTALL_OSARCH}.egg
diff -Naur gdal_1.6.0/distinfo gdal/distinfo
--- gdal_1.6.0/distinfo 2009-03-18 15:50:27.0 +0100
+++ gdal/distinfo 2010-08-01 08:11:58.0 +0200
@@ -1,3 +1,3 @@
-MD5 (gdal-1.6.0.tar.gz) = 0c53697511f489455f8b60e843986568
-SHA256 (gdal-1.6.0.tar.gz) =
acdc2faf7496f8d8f4680347ce30fd3a2139b5c050f13dcd6ca8a3d7f6e418a4
-SIZE (gdal-1.6.0.tar.gz) = 7072689
+MD5 (gdal-1.7.2.tar.gz) = 05351f8cb61761ae579667e24a297fe6
+SHA256 (gdal-1.7.2.tar.gz) =
0834909a93e955a45cf050714b018fed89f8dbe74e0381e91d16a8084ca08837
+SIZE (gdal-1.7.2.tar.gz) = 7755378
diff -Naur gdal_1.6.0/files/patch-ogr-GNUmakefile
gdal/files/patch-ogr-GNUmakefile
--- gdal_1.6.0/files/patch-ogr-GNUmakefile 2009-03-18 15:50:27.0
+0100
+++ gdal/files/patch-ogr-GNUmakefile1970-01-01 01:00:00.0 +0100
@@ -1,11 +0,0 @@
ogr/GNUmakefile.orig 2009-03-02 23:42:30.0 +0300
-+++ ogr/GNUmakefile2009-03-02 23:42:35.0 +0300
-@@ -19,7 +19,7 @@
-
- default: lib
-
--all: sublibs apps test_ogrsf$(EXE)
-+all: sublibs
-
- clean:
- rm -f html/*
___
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 version 1.7.2
gdal version 1.7.2 was released on April, 23th. There are many improvements against version 1.6.0 (from December 2008) which we found in the ports. Are there any plans to update graphics/gdal in the next time? If I could help (like testing) in some way please let me know. Thanks in advance for answering, Rainer Hurling ___ 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
