R: R: [Gdal-dev] [ANNOUNCE] gdal debian package at mentors.debia n.ne t

[Amici Alessandro]

Frank,
 
> > for now I would suggest we
> > modify the configure to allow the configurer to provide an
> > "LD_SHARED" command. The Debian build can provide one that
> > correctly sets up the -soname option.

after some experiments seems that the minimal approach without
_any_ change to gdal is the following:

- keep the configure and build system as they are,
- build with the following commands:
	ln -fs libgdal.so.$(version) libgdal.so
	ln -fs libgdal.so.$(version) libgdal.so.$(sover)
	$(MAKE) LD_SHARED="c++ -shared -Wl,-soname,libgdal.so.$(sover)"\
		GDAL_SLIB=libgdal.so.$(version) \
		GDAL_SLIB_LINK="-L$(CURDIR) -lgdal"
  where version=1.1.9 and sover=1
  this builds libgdal.so.1.1.9 with soname libgdal.so.1 and all the
  binaries and the python module seem ok, but...

unfortunately while building _gdalmodule.so you (rightly) use
$(LD_SHARED), so it gets the gdal soname as well :-/. 
this gives no visible problem, but it's ugly.

in order to allow a clean build for a sonamed library
i'd need at the minimum the following patch:

--- GNUmakefile.orig	2003-05-21 10:15:32.000000000 +0200
+++ GNUmakefile	2003-05-21 10:57:10.000000000 +0200
@@ -10,7 +10,7 @@
 force-lib:	
 	$(AR) r $(GDAL_LIB) $(GDAL_OBJ)
 	$(RANLIB) $(GDAL_LIB)
-	$(LD_SHARED) $(GDAL_OBJ) $(GDAL_LIBS) $(LIBS) -o $(GDAL_SLIB)
+	$(LD_SHARED) $(GDAL_SLIB_SONAME) $(GDAL_OBJ) $(GDAL_LIBS) $(LIBS) -o
$(GDAL_SLIB)
 
 #	If you really want proper SO files that will work in /usr/lib
 # 	Try replacing the above command with something like this:
@@ -23,7 +23,7 @@
 	$(RANLIB) $(GDAL_LIB)
 
 $(GDAL_SLIB):	$(GDAL_LIB) $(GDALA_DEP)
-	$(LD_SHARED) $(GDAL_OBJ) $(GDAL_LIBS) $(LIBS) -o $(GDAL_SLIB)
+	$(LD_SHARED) $(GDAL_SLIB_SONAME) $(GDAL_OBJ) $(GDAL_LIBS) $(LIBS) -o
$(GDAL_SLIB)
 
 check-lib:
 	$(MAKE) $(GDAL_LIB)


this way i can build with:
	$(MAKE) GDAL_SLIB_SONAME="-Wl,-soname,libgdal.so.$(sover)" \
		GDAL_SLIB=libgdal.so.$(version) \
		GDAL_SLIB_LINK="-L$(CURDIR) -lgdal"
avoiding any side effect.

> in order to avoid future naming conflicts, is it ok if i use:
> 	LD_SHARED = ld -shared -Wl,-soname,libgdal.so.1.1.9
> i think 1.1 is not enough (but i may be wrong) and since the 
> last released version is 1.1.8 i'd better not use that number,
> just in case someone tweaked the makefiles of the stable
> version (i.e. i did).
> what's your opinion? (i'm not sure i understood the soname
> mechanism that deeply :)

i checked the libraries on my debian system and looks like all
sonames are in the form libfoo.so.N with N being a one-digit 
soversion. i choosed soversion 1 for gdal.
if gdal has to follow this convention it is important that the 
soversion is incremented by one digit every time backward binary 
compatibility is broken (judging from the name libgdal.1.1.so i 
guess 1.0 is not compatible with 1.1).

please apply the will-be-broken-by-outlook-but-i-couldnt-avoid-it
patch,
alessandro