Обсуждение: shared library strangeness?
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
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, Pennsylvania19026
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