Skip site navigation (1) Skip section navigation (2)

Re: shared library strangeness?

From: ncm(at)zembu(dot)com (Nathan Myers)
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: shared library strangeness?
Date: 2001-07-02 18:58:15
Message-ID: 20010702115815.B1466@store.zembu.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Mon, Jul 02, 2001 at 09:29:23AM -0700, Bill Studenmund wrote:
> On Tue, 22 May 2001, Bruce Momjian wrote:
> 
> > I am always confused when to bump the minor and when the major.  I also
> > was not sure how significant the change would be for apps.  We added
> > const, and I changed the return type of one function from short to int. 
> > Seems like ConnectionBad was also changed.
> 
> You need to bump the minor whenever you add to the library. You need to
> bump the major whenever you delete from the library or change(*) the
> interface to a function. i.e. if a program links against the library, as
> long as the routine names it linked against behave as it expected at
> compile time, you don't need to bump the major.
> 
> (*) NetBSD (and I think other OSs too) use a gcc-ism, RENAME, to be able
> to change the interface seen by new programs w/o changing the minor
> number. What you do is prototype the function as you want it now, and have
> a __RENAME(new_name) at the end of the prototype. When you build the
> library, you have a routine having the old footprint and old name, and a
> new routine with the new footprint and named new_name. Old programs look
> for the old name, and get what they expect. New programs look for the new
> name, and also get what they expect.

GNU binutils, Solaris ld, and other complete implementations of the ELF 
standard also support "symbol versioning", which IIUC doesn't require
compiler support.  This apparatus was used, for example, in Gnu libc to 
add binary-backward-compatible support for a 64-bit file positioning
without need to change the source-level interface.

Of course just prepending a "new_" prefix would be a poor choice of 
version naming convention.

It's possible to do this portably with elaborate macro apparatus, or (in 
C++) with namespace aliases, but it's not pretty.  Because it clutters 
header files, it can be confusing to users who depend on header files to 
supplement documentation.

Nathan Myers
ncm(at)zembu(dot)com


In response to

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2001-07-02 19:20:57
Subject: Re: Re: New data type: uniqueidentifier
Previous:From: Alex PilosovDate: 2001-07-02 18:39:23
Subject: Re: Re: New data type: uniqueidentifier

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group