[gdal-dev] packaging gdal for debian

[Frank Warmerdam]

paulbaker78 wrote:
> The problem is that gdal upstream does not build a shared library. I
> don't really have much experience with building libraries, so I'm not
> really sure quite what to do in order to make this happen. The
> combination of GNUMakefile and GDALMake.opt.in is not quite what I'm
> used to seeing. In GNUMakefile there is commented out near the top
> about using the commented out command instead of the one above in
> order to build a "proper SO files that will work in /usr/lib". This is
> of course what I need, but using that command instead of the upstream
> one doesn't seem to quite pull it off. The suggested command gives
> '-soname,gdal.so.1'. It really should be '-soname,libgdal.so.1' if I'm
> not mistaking. And besides the actual file that is created is
> libgdal.1.1.so which doesn't match either gdal.so.1 or libgdal.so.1.
> 
> Before each distribution starts packaging up gdal in different ways
> with different sonames which will then completely break binary
> compatibility with programs trying to work with the shared library
> version from one distribution to another, upstream needs to hurry up
> and spell out just how it's going to be.
> 
> Frank, if you are reading this, how open are you to working on getting
> real shared library build targets included in the upstream source? I
> hope you are willing before it is too late.

Paul,

I'm not sure why you say that GDAL doesn't build a shared library. I
assume you mean it doesn't produce a shared library with the usual
naming conventions. Is that right?

After soon initial hesitancy, I am now willing to revise how I build the
shared library to conform when conventions. I won't use libtool for reasons
I have tried to explain before, but I am willing to modify the configure
scripts to build with conventional names, and using -soname and so forth
set things right.

Hopefully we can roll this out as a GDAL 1.1.8 release in the relatively
near future.

Before I go digging for more details tomorrow, can anyone point me to what
I should be using as a link command on Linux?

Also, on the issue of having the separate development package. I am also
willing to separate out an install-slib, install-dev, install-bin and
install-all targets which would do:

install-slib: Just installs libgdal.so.1.x and support shared data.

install-bin: Installs various programs, and requires install-slib.

install-lib: Installs static library and include files.

install-all: Does all of the above.

I am also willing to review how GDAL installs figure out where to put python.
Currently I used a bunch of custom configure logic to find where python modules
belong, and try to install there. Often somewhere like /usr/lib/python2.0/site-packages.
This gets put in the INST_PYMOD macro in GDALmake.opt, which can be overridden
on the make commandline if need be. But there have been complaints that I don't
honour --prefix settings for the python install. The problem is that the python
modules can't work if they aren't installed where python is, unless people extend
their PYTHONPATH or something. So what exactly do people want, and how will it
produce a useful install tree?

PS. I run debian, but generally hesitate to install .debs for stuff like PROJ.4
and GDAL for fear of confusing my local working configuration. I already have
problems from having an installed copy of stuff in /usr/local and my local builds
at times. I suppose I ought to setup an alternate bootable root on my system for
testing stuff like this.

PPS. I would love to see a centralized package of gis/rs related debs accumulated
somewhere like remotesensing.org. I can provide system access if this is felt to
be a good idea. Does it make sense to do the same thing for rpms or should we
leave this to the freegis guys who are already producing rpms for the freegis CDs
anyways? Is there a redhat/rpm equilvelent to apt-get and co?

PPPS. I think we should have a mailing list or something for discussions of packaging
of gis/rs related packages for debian. To avoid duplication, and to ensure that the
various related technologies (GRASS, MapServer, PROJ.4, GDAL, OpenEV) can work together
properly.

Best regards,

-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam at p...
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent