This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]