gdal, proj4, Re: libgeotiff-1.2.1-2 (sqlite, libjasper, python, libtool)

[Reini Urban]

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 maintainer, norman :)
fixed everything now.

I also think that it will be better to link postgres
at run-time with dlopen, so that it is not required, just optional.
And I can try various filenames to dlopen:
/usr/bin/pg.dll (7.x style) and my new cygpg.dll (when it will be accepted).

>>ok? or more? KAKADU is funny nick for JPEG2000 I assume.

but jpeg2000 support is in.

>>MrSID is non-free. everything else can be added on request.

Ok, I'll build mapserver and postgis first, and then I'll see,
what we need to get mapserver and postgis running.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/