[gdal-dev] Re: GDAL Driver Changes

Daniel Morissette danmo at v...
Fri Jun 21 11:05:03 EDT 2002


paulbaker78 wrote:
> 
> This is exactly what SONAME is for, which we talked about in the other
> thread I started a week or two back. This is really important that it
> should probably be worked out by the next release (1.1.8? 1.2.0?
> 2.0.0?) so that people can start to rely on it. IMUIC, that means gdal
> should install something to the affect of:
> 
> libgdal.so.<release_version>
> libgdal.so.<binary compatibility version or SONAME> which is symlinked
> to the libgdal.so.<release_version>.
> 
> The above files would be what is required of a program to run an
> already compiled binary.
> 
> For building things with gdal, then you also should have a libgdal.so
> file that is symlinked to the libgdal.so.<SONAME> file.
> 
> So what would this look like for a 1.2.0 release?
> 
> libgdal.so.1.2.0
> libgdal.so.1 -> libgdal.so.1.2.0
> libgdal.so -> libgdal.so.1
> 
> Anyway that is my understanding of it, I could be wrong.
> 
> Of course if with every release of gdal, it breaks binary
> compatibility, you may be saying, doesn't the SONAME then increase to
> 2? does that mean you have to call it gdal 2.something? No. You may
> know that libfreetype is at 6, yet the version number is only at 2.1.1
> IIRC.
> 
> 


Frank, Paul,

I think Paul is right, GDAL should install libraries named this way:

libgdal.so.1.2.0
libgdal.so.1 -> libgdal.so.1.2.0
libgdal.so -> libgdal.so.1

I never saw the real use for this until recently when I decided to
install a new (custom) GD on a system that came preinstalled with its
own libgd.so ... then I understood how those naming conventions could be
useful. The nice thing is that with names as suggested above, the linker
remembers only the reference to the physical file when you use -lgdal
(libgdal.so.1.2.0 in this case), so when you upgrade your libs later you
leave the libgdal.so.1.2.0 there and the old executables keep working
against it, but the libgdal.so logical link is replaced to point to a
newer file (libgdal.so.1.2.1 or whatever), in sync with the installed
header files that will be used to build/link new programs in the future.

The way things are right now with the name libgdal.1.1.so, rebuilding
GDAL often breaks old executables, it would really be nice if the above
approach could be used, and then I could easily keep older and newer
versions of MapServer at the same time on the same server. :)

I know how busy you are (same here)... but I just wanted to add my
0.02$...
-- 
------------------------------------------------------------
Daniel Morissette morissette at d...
DM Solutions Group http://www.dmsolutions.ca/
------------------------------------------------------------
Don't put for tomorrow what you can do today, because if 
you enjoy it today you can do it again tomorrow.




More information about the Gdal-dev mailing list