Thread: Bumping libpq version number?
Are we still bumping the libpq major version number for 8.0.2? I think it is a bad idea because we will require too many client apps to be recompiled, and we have had few problem reports. We do need to bump the major version number for 8.1 and I am doing that now. One new problem I see is that changes to libpgport could affect client apps that call libpq because they pull functions from pgport via libpq. For example, now that snprintf is called pg_snprintf, my initdb failed in the regression tests because the the new initdb binary used pg_snprintf but the installed libpq (ld.so.conf) didn't have it yet. The bottom line is that we only used to require major libpq version bumps when we changed the libpq API. Now, with libpgport, I am concerned that changes in libpgport also will require a major version bump. This adds support to the idea that we will have to do a major libpq bump for every major release. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
* Bruce Momjian (pgman@candle.pha.pa.us) wrote: > Are we still bumping the libpq major version number for 8.0.2? I think > it is a bad idea because we will require too many client apps to be > recompiled, and we have had few problem reports. > > We do need to bump the major version number for 8.1 and I am doing that > now. > > One new problem I see is that changes to libpgport could affect client > apps that call libpq because they pull functions from pgport via libpq. > For example, now that snprintf is called pg_snprintf, my initdb failed > in the regression tests because the the new initdb binary used > pg_snprintf but the installed libpq (ld.so.conf) didn't have it yet. > > The bottom line is that we only used to require major libpq version > bumps when we changed the libpq API. Now, with libpgport, I am > concerned that changes in libpgport also will require a major version > bump. This adds support to the idea that we will have to do a major > libpq bump for every major release. Uh, major libpq version bumps should happen when there's an incompatible ABI change. I'm not entirely sure how libpgport relates, but libpq versions shouldn't be explicitly linked to major release numbers and it's possible for them to change between major releases... Stephen
Kurt Roeckx wrote: > On Fri, Mar 11, 2005 at 12:58:28PM -0500, Bruce Momjian wrote: > > Are we still bumping the libpq major version number for 8.0.2? I think > > it is a bad idea because we will require too many client apps to be > > recompiled, and we have had few problem reports. > > > > We do need to bump the major version number for 8.1 and I am doing that > > now. > > > > One new problem I see is that changes to libpgport could affect client > > apps that call libpq because they pull functions from pgport via libpq. > > For example, now that snprintf is called pg_snprintf, my initdb failed > > in the regression tests because the the new initdb binary used > > pg_snprintf but the installed libpq (ld.so.conf) didn't have it yet. > > Does initdb call pg_snprintf directly? Or does it call some > libpq function that calls it? With the current CVS, initdb calls pg_snprintf() on my platform which doesn't support %$ natively on my libc printf. Now, initdb could pull from pgport itself but I think it pulled from libpq first. Perhaps we should reorder how those libraries appear in the link line but I think that would fix just this case, not the more general one of pg client apps. > > The bottom line is that we only used to require major libpq version > > bumps when we changed the libpq API. Now, with libpgport, I am > > concerned that changes in libpgport also will require a major version > > bump. This adds support to the idea that we will have to do a major > > libpq bump for every major release. > > Soname changes really should only happen in case of API or ABI > changes and I think you really should try to avoid them. I'm not > sure why you think it's required now. We had the problem with 8.0.X where we remove get_progname from libpq and psql and friends were pulling that from libpq in the past for 7.4. > Also, I think it's alot better to actually do soname changes to > libraries if things can break. I don't see having 2 library > versions around as a problem. And I'd rather have something I > just know is not going to work. Yes, that is where I am leaning in this discussion because libpgport varies much more frequently than the libpq API. However, changing the link order should fix that so let me do that and see if it helps. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Kurt Roeckx wrote: > On Fri, Mar 11, 2005 at 01:29:46PM -0500, Bruce Momjian wrote: > > Kurt Roeckx wrote: > > > > > > Does initdb call pg_snprintf directly? Or does it call some > > > libpq function that calls it? > > > > With the current CVS, initdb calls pg_snprintf() on my platform which > > doesn't support %$ natively on my libc printf. Now, initdb could pull > > from pgport itself but I think it pulled from libpq first. Perhaps we > > should reorder how those libraries appear in the link line but I think > > that would fix just this case, not the more general one of pg client > > apps. > > Do "client apps" ever link to pgport itself? I assume only > "internal" applictions link to it? They do. > I assume libpq is staticly linked to pgport and is exporting > symbols it shouldn't. Can we prevent it from exporting those > symbols? I can think of no way to prevent it, except on Win32 that has an exports file. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian wrote: > Are we still bumping the libpq major version number for 8.0.2? Yes. > I > think it is a bad idea because we will require too many client apps > to be recompiled, That is not true, as previously discussed. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut wrote: > Bruce Momjian wrote: > > Are we still bumping the libpq major version number for 8.0.2? > > Yes. > > > I > > think it is a bad idea because we will require too many client apps > > to be recompiled, > > That is not true, as previously discussed. It is not true only if the old libpq stays around, which isn't always the case. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
pgman wrote: > Peter Eisentraut wrote: > > Bruce Momjian wrote: > > > Are we still bumping the libpq major version number for 8.0.2? > > > > Yes. > > > > > I > > > think it is a bad idea because we will require too many client apps > > > to be recompiled, > > > > That is not true, as previously discussed. > > It is not true only if the old libpq stays around, which isn't always > the case. In fact, based on the few complaints we have heard about the current situation, I am sure we are going to get many more complaints if we bump up the major version in 8.0.2. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian wrote: > It is not true only if the old libpq stays around, which isn't always > the case. I think that would clearly be a Don't-do-that-then situation. -- Peter Eisentraut http://developer.postgresql.org/~petere/
On Fri, 11 Mar 2005, Bruce Momjian wrote: > Peter Eisentraut wrote: >> Bruce Momjian wrote: >>> Are we still bumping the libpq major version number for 8.0.2? >> >> Yes. >> >>> I >>> think it is a bad idea because we will require too many client apps >>> to be recompiled, >> >> That is not true, as previously discussed. > > It is not true only if the old libpq stays around, which isn't always > the case. that's an administrative decision though, not ours ... we have source code going back to 6.x, so it isn't like older versions aren't available ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Bruce Momjian wrote: > In fact, based on the few complaints we have heard about the current > situation, I am sure we are going to get many more complaints if we > bump up the major version in 8.0.2. The lack of complaints is because the packagers that have recognized the problem are refusing the package PostgreSQL 8.0 until the problem is resolved. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut wrote: > Bruce Momjian wrote: > > In fact, based on the few complaints we have heard about the current > > situation, I am sure we are going to get many more complaints if we > > bump up the major version in 8.0.2. > > The lack of complaints is because the packagers that have recognized the > problem are refusing the package PostgreSQL 8.0 until the problem is > resolved. OK, I will bump them. What should I do with 8.1? Make it another major bump? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On 2005-03-11, Bruce Momjian <pgman@candle.pha.pa.us> wrote: > Kurt Roeckx wrote: >> I assume libpq is staticly linked to pgport and is exporting >> symbols it shouldn't. Can we prevent it from exporting those >> symbols? > > I can think of no way to prevent it, except on Win32 that has an exports > file. At least a significant minority, if not an actual majority, of Unix platforms do allow this; including (to my knowledge) Solaris, AIX and everything using ELF with GNU ld (therefore including Linux and FreeBSD). -- Andrew, Supernews http://www.supernews.com - individual and corporate NNTP services
Andrew - Supernews wrote: > On 2005-03-11, Bruce Momjian <pgman@candle.pha.pa.us> wrote: > > Kurt Roeckx wrote: > >> I assume libpq is staticly linked to pgport and is exporting > >> symbols it shouldn't. Can we prevent it from exporting those > >> symbols? > > > > I can think of no way to prevent it, except on Win32 that has an exports > > file. > > At least a significant minority, if not an actual majority, of Unix > platforms do allow this; including (to my knowledge) Solaris, AIX and > everything using ELF with GNU ld (therefore including Linux and FreeBSD). OK, how is this done with ELF? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On 2005-03-13, Bruce Momjian <pgman@candle.pha.pa.us> wrote:
> Andrew - Supernews wrote:
>> On 2005-03-11, Bruce Momjian <pgman@candle.pha.pa.us> wrote:
>> > I can think of no way to prevent it, except on Win32 that has an exports
>> > file.
>>
>> At least a significant minority, if not an actual majority, of Unix
>> platforms do allow this; including (to my knowledge) Solaris, AIX and
>> everything using ELF with GNU ld (therefore including Linux and FreeBSD).
>
> OK, how is this done with ELF?
Using version commands in a linker script file.
The minimal example looks about like this (for GNU ld, for Solaris ld
leave off the outer VERSION { } wrapper):
VERSION { { global: foo; bar; baz; local: *; };
}
This makes all symbols other than "foo", "bar" and "baz" into local symbols,
not visible outside the library.
This much of the Solaris-style symbol versioning support is handled entirely
in the linker and thus should work on any system with ELF and GNU ld, or on
Solaris with the native linker. (The rest requires runtime support, which
probably doesn't exist on platforms other than Solaris.)
--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services
On Fri, Mar 11, 2005 at 04:49:23PM -0500, Bruce Momjian wrote: > > In fact, based on the few complaints we have heard about the current > situation, I am sure we are going to get many more complaints if we bump > up the major version in 8.0.2. I think it's better to have people complain that they should rebuild than complaining that it's broken. Note that you actually might force other people (OSs) to do the transition, not to break their system. You make it alot easier for them if you actually do transition yourself so the sonames do not get out of sync. It's quite annoying that you do not bump the soname when you should. Kurt
On Fri, Mar 11, 2005 at 01:29:46PM -0500, Bruce Momjian wrote: > Kurt Roeckx wrote: > > > > Does initdb call pg_snprintf directly? Or does it call some > > libpq function that calls it? > > With the current CVS, initdb calls pg_snprintf() on my platform which > doesn't support %$ natively on my libc printf. Now, initdb could pull > from pgport itself but I think it pulled from libpq first. Perhaps we > should reorder how those libraries appear in the link line but I think > that would fix just this case, not the more general one of pg client > apps. Do "client apps" ever link to pgport itself? I assume only "internal" applictions link to it? I assume libpq is staticly linked to pgport and is exporting symbols it shouldn't. Can we prevent it from exporting those symbols? Kurt
On Fri, Mar 11, 2005 at 12:58:28PM -0500, Bruce Momjian wrote: > Are we still bumping the libpq major version number for 8.0.2? I think > it is a bad idea because we will require too many client apps to be > recompiled, and we have had few problem reports. > > We do need to bump the major version number for 8.1 and I am doing that > now. > > One new problem I see is that changes to libpgport could affect client > apps that call libpq because they pull functions from pgport via libpq. > For example, now that snprintf is called pg_snprintf, my initdb failed > in the regression tests because the the new initdb binary used > pg_snprintf but the installed libpq (ld.so.conf) didn't have it yet. Does initdb call pg_snprintf directly? Or does it call some libpq function that calls it? > The bottom line is that we only used to require major libpq version > bumps when we changed the libpq API. Now, with libpgport, I am > concerned that changes in libpgport also will require a major version > bump. This adds support to the idea that we will have to do a major > libpq bump for every major release. Soname changes really should only happen in case of API or ABI changes and I think you really should try to avoid them. I'm not sure why you think it's required now. Also, I think it's alot better to actually do soname changes to libraries if things can break. I don't see having 2 library versions around as a problem. And I'd rather have something I just know is not going to work. Kurt