[gdal-dev] packaging gdal for debian
tapadmin at s...
Fri Jun 7 00:56:11 EDT 2002
First off, your gdal/ogr/proj libraries are peachy-keen and I use them a
lot, I work as a subcontractor for several USG contractors and my products
wouldn't be possible without you, cheers! :)
After reading all these posts I wanted to throw in a response/question
regarding gdal/ogr and integration with VTK. Frank may remember last fall I
sent him a personal email informing him I had written a gdal/ogr/proj
wrapper for the AVS/Express visualization system. Since then AVS has tanked
and my customers have all started migrating to the VTK Visualization Toolkit
for their visualization apps.
VTK from www.kitware.com or public.kitware.com provides a tool for cross
platform projects named Cmake (currently 1.4 beta) that it seems would be
ideal for the gdal/ogr/proj/grass/... projects.
You basically provide a list of *.c, *.cpp, *.cxx files, headers, libraries
and hit the OK button. Cmake then builds your project files for you. It
works great on my winders and linux boxes, has anyone else tried it?
Why not use it??, it is released under the MIT license, same as GDAL/OGR
Enlightment is always appreciated.
From: Frank Warmerdam [mailto:warmerdam at p...]
Sent: Thursday, June 06, 2002 11:26 PM
To: gdal-dev at yahoogroups.com
Subject: Re: [gdal-dev] packaging gdal for debian
> 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.
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
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
Currently I used a bunch of custom configure logic to find where python
belong, and try to install there. Often somewhere like
This gets put in the INST_PYMOD macro in GDALmake.opt, which can be
on the make commandline if need be. But there have been complaints that I
honour --prefix settings for the python install. The problem is that the
modules can't work if they aren't installed where python is, unless people
their PYTHONPATH or something. So what exactly do people want, and how will
produce a useful install tree?
PS. I run debian, but generally hesitate to install .debs for stuff like
and GDAL for fear of confusing my local working configuration. I already
problems from having an installed copy of stuff in /usr/local and my local
at times. I suppose I ought to setup an alternate bootable root on my
testing stuff like this.
PPS. I would love to see a centralized package of gis/rs related debs
somewhere like remotesensing.org. I can provide system access if this is
be a good idea. Does it make sense to do the same thing for rpms or should
leave this to the freegis guys who are already producing rpms for the
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
of gis/rs related packages for debian. To avoid duplication, and to ensure
various related technologies (GRASS, MapServer, PROJ.4, GDAL, OpenEV) can
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
More information about the Gdal-dev