FAQ
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

Search Discussions

  • Bruce Momjian at May 22, 2001 at 11:23 am
    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
  • Bill Studenmund at Jul 2, 2001 at 4:27 pm

    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
  • Nathan Myers at Jul 2, 2001 at 6:58 pm

    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedMay 21, '01 at 3:13p
activeJul 2, '01 at 6:58p
posts4
users4
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase