RE: gdal, proj4, Re: libgeotiff-1.2.1-2 (sqlite, libjasper, python, libtool)
Reini Urban writes: norman: does libgdal really needs libpython at all? does it have an embedded python interpreter? I only saw the python extension, which builds its seperate python gdal modules. but nothing which refers to python within the library itself. I want to remove -lpython2.3 from LIBS You can safely remove libpython from LIBS libpython is only needed for the Python extension LIBTIFF support: external you shoul duse the internal tiff library as it is 'gauranteed' to be in sync with the internal libgeotiff i.e. configure --with-libtiff=internal --with-geotiff=internal HTH Norman
Re: libgeotiff-1.2.1-2
Hello Reini,
Am Freitag, 8. Oktober 2004 um 05:43 schriebst du:
Reini Urban schrieb:
Norman Vine schrieb:
Proj4 http://proj.maptools.org/ should build OTB
well, we want it shared. add this to some lib srcfile: src/geocent.c
#ifdef __CYGWIN__
int main(int argc, char **argv) { }
#endif
./configure --prefix=/usr --mandir=/usr/share/man
make AM_LDFLAGS=-no-undefined
make install
Charles' ready to use package probably takes care of all this and of
course provides shared libraries.
[...]
Since I will maintain postgis probably it will make sense if I maintain
these helper libs also. GIS is one of my native fields.
Latest postgresql from today fixed most outstanding issues (just one new
error), even the plperl problem was found, so I'll try out PostGIS
and will ITP this also then.
Gerrit
--
=^..^=
Re: libgeotiff-1.2.1-2
Gerrit P. Haase schrieb:
Hello Reini,
Am Freitag, 8. Oktober 2004 um 05:43 schriebst du:
Norman Vine schrieb:
Proj4 http://proj.maptools.org/ should build OTB
well, we want it shared. add this to some lib srcfile: src/geocent.c
#ifdef __CYGWIN__
int main(int argc, char **argv) { }
#endif
./configure --prefix=/usr --mandir=/usr/share/man
make AM_LDFLAGS=-no-undefined
make install
Charles' ready to use package probably takes care of all this and of
course provides shared libraries.
Well, as it turned out proj4 is not yet dll ready.
This is a known issue and should be fixed upstream.
gdal expects it as static.
no problem, it is small.
but geos-2.0.1 goes ok as shared. (with added -no-undefined)
/bin/cyggeos-2.dll 8MB
Re: libgeotiff-1.2.1-2
Reini Urban wrote: but geos-2.0.1 goes ok as shared. (with added -no-undefined) /bin/cyggeos-2.dll 8MB You shpuld strip the DLL;) Gerrit
gdal, proj4, Re: libgeotiff-1.2.1-2 (sqlite, libjasper, python, libtool)
Reini Urban schrieb:
Gerrit P. Haase schrieb:
Hello Reini,
Am Freitag, 8. Oktober 2004 um 05:43 schriebst du:
Norman Vine schrieb:
Proj4 http://proj.maptools.org/ should build OTB
well, we want it shared. add this to some lib srcfile: src/geocent.c
#ifdef __CYGWIN__
int main(int argc, char **argv) { }
#endif
wrong.
./configure --prefix=/usr --mandir=/usr/share/man
make AM_LDFLAGS=-no-undefined
make install
Charles' ready to use package probably takes care of all this and of
course provides shared libraries.
true.
Well, as it turned out proj4 is not yet dll ready.
wrong. Charles' -Wl,--enable-runtime-pseudo-reloc fixed it.
This is a known issue and should be fixed upstream.
just for the records: just 2 tiny patches were needed.
or go like this:
libtoolize -f; autoreconf -f -i -s
LDFLAGS=-Wl,--enable-runtime-pseudo-reloc ./configure --prefix=/usr \
--mandir=/usr/share/man
make AM_LDFLAGS=-no-undefined
make install
cygproj-0.dll: unstripped 595KB, stripped 188KB
gdal expects it as static.
no problem, it is small.
gdal:
libtoolize -f; autoreconf -f -i -s
./configure --prefix=/usr --mandir=/usr/share/man \
--with-sqlite --with-xerces
make make install
After adding -Wl,--enable-runtime-pseudo-reloc and -no-undefined to the
$(LIBGDAL): target it builds shared also.
There need to be some port4 structs initialized.
I also had to -lproj manually to the LIBS in the makefile. (or patch
configure.in)
This is how I'll do gdal and postgis now, dependant on some not yet
available shared libs:
sqlite is still not official (jaari: shared?), but I'll link against a
shared cygsqlite3-0.dll nevertheless.
since there's no libodbc yet (gerrit? I didn't find it on
http://anfaenger.de/cygwin/), no ODBC support. those folks should recompile.
libjasper: ping
libjasper.la has a strange
dependency_libs=' -L/usr/X11R6/lib /usr/lib/libjpeg.la'
line. This will for example link against /usr/X11R6/bin/libz.dll then...
postgresql:
I found out that a libpq.dll.a import lib is needed, so I'll add that to
my postgresql-8.0.0cvs-2 todo list. And have that added upstream also.
And I really want to add the cyg prefix to some of their /usr/bin/ dll's
(libpq only probably) to have them seperate from the mingw versions
which flow around. (and libtool seems to prefer that. see python)
Persuading them to use libtool or at least some dll versioning will not
be possible, but I'll have a try.
python (or libtool) is still kind of stupid.
without some tricks it will prevent building a shared libgdal:
--mode=install
*** Warning: linker path does not have real file for library
-lpython2.3.dll.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libpython2.3.dll and none of the candidates passed a file
format test
*** using a file magic. Last file checked:
/usr/lib/python2.3/config/libpython2.3.dll.a
This looks like a libtool-1.5.10 bug. Should I really add /usr/bin/ to
the linker path? There is a /usr/bin/libpython2.3.dll or does libtool
only check for cyg prefixes?
even copying it to cygpython2.3.dll didn't work.
I also find the relinking on mode=install very annoying. Copying the
libs verbatim, and fixing the la by hand will make it workable.
relink is not only unnecessary (charles will disagree), it also fails.
(on python, jasper, pg)
Anyway, to focus on topic:
So we don't need any libgeotiff at all. Do we?
libgdal contains it and much more.
==
GDAL is now configured for i686-pc-cygwin
Installation directory:/usr
C compiler:gcc -O2
C++ compiler: g++ -O2
LIBTOOL support: yes
LIBZ support: external
GRASS support: no
CFITSIO support: no
NETCDF support:no
LIBPNG support:external
LIBTIFF support: external
LIBGEOTIFF support:internal
LIBJPEG support: external
LIBGIF support:internal
OGDI support: no
HDF4 support: no
KAKADU support:no
JASPER support:yes (GeoJP2=no)
ECW support: no
MrSID support: no
POSTGRESQL support:yes
XERCES support:no
ODBC support: no
OCI support: no
DODS support: no
SQLite support:yes
GEOS support: yes
Statically link PROJ.4:no
Python:yes
enable OGR building: yes
checking how to link PROJ.4 library... link dynamically.
ok? or more? KAKADU is funny nick for JPEG2000 I assume.
MrSID is non-free. everything else can be added on request.
but geos-2.0.1 goes ok as shared. (with added -no-undefined)
/bin/cyggeos-2.dll 8MB
bang on my head! thanks gerrit
stripped
Re: gdal, proj4, Re: libgeotiff-1.2.1-2 (sqlite, libjasper, python, libtool)
Hello Reini, since there's no libodbc yet (gerrit? I didn't find it on http://anfaenger.de/cygwin/), no ODBC support. those folks should recompile. Hmmm, I can provide a package in about an hour or two. Well, which library is wanted here, there are several possible: unixODBC libiodbc freetds http://anfaenger.de/cygwin/cygwin-1.5/freetds/ Gerrit -- =^..^=
Re: gdal, proj4, Re: libgeotiff-1.2.1-2 (sqlite, libjasper, python, libtool)
Gerrit P. Haase schrieb:
Hello Reini,
since there's no libodbc yet (gerrit? I didn't find it on
http://anfaenger.de/cygwin/), no ODBC support. those folks should
recompile.
Hmmm, I can provide a package in about an hour or two.
not THAT fast. one or two days will be enough.
libjasper: ping
libjasper.la has a strange
dependency_libs=' -L/usr/X11R6/lib /usr/lib/libjpeg.la'
line. This will for example link against /usr/X11R6/bin/libz.dll
then...
No, if you have libz.dll in /usr/X11R6/bin then delete it. It is not
part of the Cygwin distribution. Besides that there is nothing
strange with the dependency to libjpeg, however, I wonder why there is
the X11 library path.
X11: annoying.
libz: good to know. heaven knows what kind of old cygnome stuff I still
have there.
[...]
python (or libtool) is still kind of stupid.
without some tricks it will prevent building a shared libgdal:
--mode=install
*** Warning: linker path does not have real file for library
-lpython2.3.dll.
If you say: -lpython2.3 instead of the above it should work, if it
breaks then it is a bug, how to reproduce it?
ok, wrong configure.in
reproduce: default build.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libpython2.3.dll and none of the candidates passed a file
format test
*** using a file magic. Last file checked:
/usr/lib/python2.3/config/libpython2.3.dll.a
This looks like a libtool-1.5.10 bug. Should I really add /usr/bin/ to
the linker path? There is a /usr/bin/libpython2.3.dll or does libtool
only check for cyg prefixes?
No, no. Use: -L/usr/lib/python2.3/config -lpython2.3
That was the first I tried of course. mode=relink failed then.
will disable that.
norman:
does libgdal really needs libpython at all?
does it have an embedded python interpreter?
I only saw the python extension, which builds its seperate python gdal
modules. but nothing which refers to python within the library itself.
I want to remove -lpython2.3 from LIBS
even copying it to cygpython2.3.dll didn't work.
I also find the relinking on mode=install very annoying. Copying the
Apply my patch, here again:
$ diff -ud ltmain.sh.old ltmain.sh
--- ltmain.sh.old 2004-10-08 01:56:36.797564800 +0200
+++ ltmain.sh 2004-10-02 02:24:08.852576000 +0200
@@ -2416,7 +2416,7 @@
{ test $prefer_static_libs = no || test -z $old_library; }; then
if test $installed = no; then
notinst_deplibs=$notinst_deplibs $lib
- need_relink=yes
+ need_relink=no
fi
# This is a shared library
Charles promised to think about it.
libs verbatim, and fixing the la by hand will make it workable.
relink is not only unnecessary (charles will disagree), it also fails.
(on python, jasper, pg)
Do you remember why it is neccessary? Charles couldn't and I never
heard about it, only thing I remember is that there was some
discussion to remove the relink stage.
ok. but it's strange. he said, that it just burns CPU.
but in my case the relinking step detects something which disables
shared building suddenly.
I fixed pq.dll, jasper.la,
and python fails probably because of the hardcoded .dll suffix.
Will check again. building requires some hour or so now (started trashing).
Anyway, to focus on topic:
So we don't need any libgeotiff at all. Do we?
libgdal contains it and much more.
==
GDAL is now configured for i686-pc-cygwin
Installation directory:/usr
C compiler:gcc -O2
C++ compiler: g++ -O2
LIBTOOL support: yes
LIBZ support: external
GRASS support: no
CFITSIO support: no
NETCDF support:no
LIBPNG support:external
LIBTIFF support: external
LIBGEOTIFF support:internal
LIBJPEG support: external
LIBGIF support:internal
OGDI support: no
HDF4 support: no
KAKADU support:no
JASPER support:yes (GeoJP2=no)
What is GeoJP2? Do I need to rebuld Jasper?
we'll have to ask norman.
ECW support: no
MrSID support: no
POSTGRESQL support:yes
XERCES support:no
ODBC support: no
Xerces is available, I'll offer iODBC soon.
xerces is optional. I'll add it manually.
iODBC must not be super-duper ITP ready.
just somethink to link against, for me to test it.
OCI support: no
DODS support: no
SQLite support:yes
GEOS support: yes
Statically link PROJ.4:no
Python:yes
enable OGR building: yes
checking how to link PROJ.4 library... link dynamically.
talked with the quasi gdal cygwin
Re: gdal, proj4, Re: libgeotiff-1.2.1-2 (sqlite, libjasper, python, libtool)
Hello Reini,
iODBC must not be super-duper ITP ready.
just somethink to link against, for me to test it.
Ok, I have it ready, just no README yet.
iODBC Driver Manager 3.52.1 configuration summary
=
Installation variables
layout default
prefix /usr
exec_prefix ${prefix}
Installation paths
programs${exec_prefix}/bin
include files ${prefix}/include
libraries ${prefix}/lib
manual pages${prefix}/share/man
Configuration files
odbc.ini/etc/odbc.ini
odbcinst.ini/etc/odbcinst.ini
Extensions
ODBC Version3
GUI Extensions true
ThreadSafe true
The GUI is gtk-1.2.10 based.
http://194.95.224.180/cygwin/libiodbc/
Gerrit
--
=^..^=
Re: libgeotiff-1.2.1-2
Norman Vine schrieb: Proj4 http://proj.maptools.org/ should build OTB GDAL http://gdal.maptools.org configure to use internal tiff and geotiff libs should build OTB This is better than libtiff? At least it supports much more formats. Should we drop the extra libgeotiff then, if GDAL already includes it? GEOS http://geos.refractions.net should build OTB using following % CC=c++ CXX=c++ ./configure; make PostGRES Cygwin binary and source packages PostGIS needs the configured but not compiled PostGres source package after configure install PostGIS into PostGRES contrib directory configure and make link against libgdal instead of libtiff and libgeotiff for geotiff support I'll configure --prefix=/usr and not /usr/local for proj4 and geos so that someone will have the change to propose this, and my postgis is ready in the meantime with my own private builds of the dll's. (libtool-devel-1.5.10) If Gerrit or Charles, I don't care. Latest postgresql from today fixed most outstanding issues (just one new error), even the plperl problem was found, so I'll try out PostGIS and will ITP this also then. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/
Re: libgeotiff-1.2.1-2
Reini Urban schrieb:
Norman Vine schrieb:
Proj4 http://proj.maptools.org/ should build OTB
well, we want it shared. add this to some lib srcfile: src/geocent.c
#ifdef __CYGWIN__
int main(int argc, char **argv) { }
#endif
./configure --prefix=/usr --mandir=/usr/share/man
make AM_LDFLAGS=-no-undefined
make install
GDAL http://gdal.maptools.org
configure to use internal tiff and geotiff libs
should build OTB
./configure --prefix=/usr --mandir=/usr/share/man \
--with-docdir=/usr/share/doc/gdal-1.2.3-1
make AM_LDFLAGS=-no-undefined
make install
This is better than libtiff? At least it supports much more formats.
Should we drop the extra libgeotiff then, if GDAL already includes it?
GEOS http://geos.refractions.net should build OTB
using following
% CC=c++ CXX=c++ ./configure; make
CC=c++ CXX=c++ LDFLAGS=-lstdc++ ./configure --prefix=/usr
make AM_LDFLAGS=-no-undefined
make check
make install
geos is actually a pretty impressive library and would need a perl
binding. Something for swig.
And co-written by someone I work together with libming. And postgis
also. What a coincidence.
PostGRES Cygwin binary and source packages
PostGIS needs the configured but not compiled PostGres source
package after configure install PostGIS into
PostGRES contrib directory
configure and make
link against libgdal instead of libtiff and libgeotiff for geotiff
support
I'll configure --prefix=/usr and not /usr/local for proj4 and geos
so that someone will have the change to propose this, and my postgis is
ready in the meantime with my own private builds of the dll's.
(libtool-devel-1.5.10)
If Gerrit or Charles, I don't care.
Since I will maintain postgis probably it will make sense if I maintain
these helper libs also. GIS is one of my native fields.
Latest postgresql from today fixed most outstanding issues (just one new
error), even the plperl problem was found, so I'll try out PostGIS
and will ITP this also then.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
Re: libgeotiff-1.2.1-2
Hallo Charles, +1 vote from me for libgeotiff (makes 3 IIRC, please upload). +1 vote for proj. Would you ming to included also GEOS in this set of packages? If so, +1 vote for geos. Where did THIS come from? I ITP'ed these over a year ago; surely there's a statute of limitations on ITP's? I've no objections to bringing my version up to the current upstream release and uploading them to sourceware, but geez...been trolling the list archives or what, Gerrit? Hehe, I just found PostGIS and want to try to get it up with my personal PostgreSQL database, PROJ and GEOS are optional components and I thought it may be useful to have these extensions to PostGIS, a quick search shows that at least PROJ was already proposed by you. Since then there was only one new release of PROJ, I used your version. Reini could make a PostGIS package as add on for PostgreSQL available with these prerequisites. Gerrit -- =^..^=
RE: libgeotiff-1.2.1-2
Gerrit P. Haase writes: Hallo Charles, +1 vote from me for libgeotiff (makes 3 IIRC, please upload). +1 vote for proj. Would you ming to included also GEOS in this set of packages? If so, +1 vote for geos. Where did THIS come from? I ITP'ed these over a year ago; surely there's a statute of limitations on ITP's? I've no objections to bringing my version up to the current upstream release and uploading them to sourceware, but geez...been trolling the list archives or what, Gerrit? Hehe, I just found PostGIS and want to try to get it up with my personal PostgreSQL database, PROJ and GEOS are optional components and I thought it may be useful to have these extensions to PostGIS, a quick search shows that at least PROJ was already proposed by you. Since then there was only one new release of PROJ, I used your version. Reini could make a PostGIS package as add on for PostgreSQL available with these prerequisites. Hi Gerrit, Proj4 http://proj.maptools.org/ should build OTB GDAL http://gdal.maptools.org configure to use internal tiff and geotiff libs should build OTB GEOS http://geos.refractions.net should build OTB using following % CC=c++ CXX=c++ ./configure; make PostGRES Cygwin binary and source packages PostGIS needs the configured but not compiled PostGres source package after configure install PostGIS into PostGRES contrib directory configure and make link against libgdal instead of libtiff and libgeotiff for geotiff support HTH Norman
Re: libgeotiff-1.2.1-2
Hello Charles, +1 vote from me for libgeotiff (makes 3 IIRC, please upload). +1 vote for proj. Would you ming to included also GEOS in this set of packages? If so, +1 vote for geos. Gerrit -- =^..^=
Re: libgeotiff-1.2.1-2
Gerrit P Haase writes: Hello Charles, +1 vote from me for libgeotiff (makes 3 IIRC, please upload). +1 vote for proj. Would you ming to included also GEOS in this set of packages? If so, +1 vote for geos. I think I voted +1 for both back then Gerrit Ciao Volker
Re: libgeotiff-1.2.1-2
Gerrit P. Haase wrote: Hello Charles, +1 vote from me for libgeotiff (makes 3 IIRC, please upload). +1 vote for proj. Would you ming to included also GEOS in this set of packages? If so, +1 vote for geos. Where did THIS come from? I ITP'ed these over a year ago; surely there's a statute of limitations on ITP's? I've no objections to bringing my version up to the current upstream release and uploading them to sourceware, but geez...been trolling the list archives or what, Gerrit? -- Chuck
[ITP update] libgeotiff-1.2.1-2
* Recompiled against 1.5.1 (and the new tiff, and the new proj, etc) * Documentation moved to /usr/share/* Still available from http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/release/proj/, or simply point setup.exe at http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/ -- Charles Wilson cygwin at removespam cwilson dot fastmail dot fm
