Обсуждение: Shared library version
There appear to have been changes in the shared library libpq. The default library from 6.5.3 with psql from current tree gives: olly@linda$ psql template1 ... psql: error in loading shared libraries: psql: undefined symbol: createPQExpBuffer olly@linda$ LD_PRELOAD=/usr/local/pgsql/lib/libpq.so.2.0 psql template1 ... template1=> Since the library has changed, it needs to have a new version number. -- Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight http://www.lfix.co.uk/oliver PGP key from public servers; key ID32B8FAA1 ======================================== "Be patient therefore, brethren, unto the coming ofthe Lord...Be patient; strengthen your hearts, for the coming of the Lord draweth nigh." James 5:7,8
> There appear to have been changes in the shared library libpq. > > The default library from 6.5.3 with psql from current tree gives: > > olly@linda$ psql template1 > ... > psql: error in loading shared libraries: psql: undefined symbol: > createPQExpBuffer > > olly@linda$ LD_PRELOAD=/usr/local/pgsql/lib/libpq.so.2.0 psql template1 > ... > template1=> > > Since the library has changed, it needs to have a new version number. Seems I should just kick up every minor version number for 7.0 for all interfaces. OK? -- Bruce Momjian | http://www.op.net/~candle maillist@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
"Oliver Elphick" <olly@lfix.co.uk> writes:
> There appear to have been changes in the shared library libpq.
> Since the library has changed, it needs to have a new version number.
You're right, we need to bump the number before release (and I hope we
remember!). Past practice has not been to bump the number during
development cycles, since we'd shortly have ridiculously high version
numbers if we incremented them at every development change.
libpq++ has also had API changes requiring a new version number before
release, I think --- any others?
regards, tom lane
On Mon, Jan 10, 2000 at 10:22:44AM -0500, Tom Lane wrote: > You're right, we need to bump the number before release (and I hope we > remember!). Past practice has not been to bump the number during > development cycles, since we'd shortly have ridiculously high version > numbers if we incremented them at every development change. Ehem... I do exactly that with libecpg. For simply changes not involving API changes I increment just the patch level. That's why libecpg has major version, minor version and patchlevel. I find it very difficult to keep track of the changes without changing version number. So please, do not change this number upon release. Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: Michael@Fam-Meskes.De | Use PostgreSQL!
Tom Lane wrote: >"Oliver Elphick" <olly@lfix.co.uk> writes: >> There appear to have been changes in the shared library libpq.>> Since the library has changed, it needs to have a new version number. > >You're right, we need to bump the numberbefore release (and I hope we >remember!). Past practice has not been to bump the number during >development cycles,since we'd shortly have ridiculously high version >numbers if we incremented them at every development change. Yes, but it should be bumped the first time it changes; I agree that it need not be increased during later development of the same release. A patch would be superfluous. The necessary change is simply to increment SO_MINOR_VERSION in src/interfaces/libpq/Makefile -- Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight http://www.lfix.co.uk/oliver PGP key from public servers; key ID32B8FAA1 ======================================== "Enter into his gates with thanksgiving, and into his courts with praise. Be thankful unto him, and bless his name." Psalms 100:4
On 2000-01-10, Tom Lane mentioned: > "Oliver Elphick" <olly@lfix.co.uk> writes: > > There appear to have been changes in the shared library libpq. > > Since the library has changed, it needs to have a new version number. > > You're right, we need to bump the number before release (and I hope we > remember!). Past practice has not been to bump the number during > development cycles, since we'd shortly have ridiculously high version > numbers if we incremented them at every development change. > > libpq++ has also had API changes requiring a new version number before > release, I think --- any others? It would at least be fair to bump the minor version number when you do the branch for a new version, so now we'd be at 2.1. IIRC the dynamic linker will pick the one with the higher minor version. Since we do not have any incompatible changes (?) we shouldn't bump the major version. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
On Tue, 11 Jan 2000, Peter Eisentraut wrote: > On 2000-01-10, Tom Lane mentioned: > > > "Oliver Elphick" <olly@lfix.co.uk> writes: > > > There appear to have been changes in the shared library libpq. > > > Since the library has changed, it needs to have a new version number. > > > > You're right, we need to bump the number before release (and I hope we > > remember!). Past practice has not been to bump the number during > > development cycles, since we'd shortly have ridiculously high version > > numbers if we incremented them at every development change. > > > > libpq++ has also had API changes requiring a new version number before > > release, I think --- any others? > > It would at least be fair to bump the minor version number when you do the > branch for a new version, so now we'd be at 2.1. IIRC the dynamic linker > will pick the one with the higher minor version. Since we do not have any > incompatible changes (?) we shouldn't bump the major version. libpq++ got a major number bump on my first sweep. This time through it should only need a minor since I don't forsee any operational changes, just additional functionality and bug fixes. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 128K ISDN: $24.95/mo or less - 56K Dialup: $17.95/moor less at Pop4 Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================