shared library strangeness?

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.

I bumped the minor in preparation for 7.2. Seems the major needs
bumping. I will do it now for libpq++.

I just upgraded PostgreSQL from 21 March CVS (rc1?) to May 19 16:21 GMT CVS.
I found that all my cgi/fcg scripts which use libpq++ stopped working in
the vague sense of apache mentioning an internal server error. Relinking
them cured the problem (had to do this in haste => unfortunately no more
information)

-rwxr-xr-x 1 postgres postgres 154795 Mar 21 21:28 libpq++.so.3.1
-rwxr-xr-x 1 postgres postgres 155212 May 21 14:48 libpq++.so.3.2

is the change. The programs using libpq only (not lipq++ as well) worked as
before. I am sorry, I don't have an error message to say how it is broken,
but I do have a slight feeling that maybe the major shared library number
could have been bumped up...

Ah... A clue!

Undefined PLT symbol "ConnectionBad__12PgConnection" (reloc type = 7, symnum
= 132)

quartz% nm -g libpq++.so.3.1 | grep ConnectionBad
000025e8 T ConnectionBad__12PgConnection
quartz% !:s/1/2/
nm -g libpq++.so.3.2 | grep ConnectionBad
000024fc T ConnectionBad__C12PgConnection

RCS file:
/home/projects/pgsql/cvsroot/pgsql/src/interfaces/libpq++/pgconnection.h,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- pgconnection.h      2001/02/10 02:31:30     1.10
+++ pgconnection.h      2001/05/09 17:29:10     1.11

-   int ConnectionBad();
...
+   bool ConnectionBad() const;

So I would suggest that the major number be bumped, leaving a small window
since 9 May with a problem..

Cheers,

Patrick

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

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.

Sorry for the delay.

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.

I'm not sure if Postgres needs to go to that much trouble.

Take care,

Bill

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@zembu.com