Re: 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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

* Bruce Momjian (pgman(at)candle(dot)pha(dot)pa(dot)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

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

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

On 2005-03-11, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On 2005-03-13, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> wrote:
> Andrew - Supernews wrote:
>> On 2005-03-11, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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