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

Mon, 21 May 2001 16:13:28 +0100
Patrick Welche <prlw1@newn.cam.ac.uk>
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

Tue, 22 May 2001 07:23:45 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: shared library strangeness?
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


Mon, 2 Jul 2001 09:29:23 -0700 (PDT)
Bill Studenmund <wrstuden@zembu.com>
Re: shared library strangeness?
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


Mon, 2 Jul 2001 11:58:15 -0700
ncm@zembu.com (Nathan Myers)
Re: shared library strangeness?