Thread: Re: [GENERAL] libpq.so.2.0 problem

[cc: list changed -- GENERAL bcc'd, PORTS cc'd]

Peter Eisentraut wrote:
> Lamar Owen writes:
> > I think that by packaging the RPM's to include libpq.so.2.x as simply
> > libpq.so.2 (as long as 2.x's are link-compatible), I can help alleviate
> > this problem for future builds.

> The symlink order will not be changed, other improvements are
> welcome.

I'm not asking for a change in the core tarball.

I could say more, but I've said it elsewhere, and it really doesn't
deserve repeating, as the decision to continue library versioning in the
core tarball has been made, and I'm not going to question that decision
here.

The changes I am likely to make, barring good technical reasons to not
do so are:
1.)    For RedHat 6.x RPM's (as well as RPM's for other distributions that
originally shipped PostgreSQL 6.5.x or 6.4.x), ship a symlink to
libpq.so.2.1 for libpq.so.2.0;
2.)    For all RPM's, change the symlinks to be:
    libpq.so -> libpq.so.2
    libpq.so.2 is the library itself
    libpq.so.2.x -> libpq.so.2  (so as to not break compatibility)

No changes are contemplated for libpq.so.1 compatibility -- there are
differences there -- but, of course, if sound technical reasons are
found to do so, I can deal with that as well.

I just want to make it easier to deal with our RPM's, that's all.  But,
as always, I am open to technical suggestions.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Lamar Owen writes:

> I could say more, but I've said it elsewhere, and it really doesn't
> deserve repeating, as the decision to continue library versioning in the
> core tarball has been made, and I'm not going to question that decision
> here.

(If you're arguing against versions in shared libraries you're up against
much higher powers than PostgreSQL.)

I've found the problem.  Trond was right, it was the fact that the
programs are linked against libpq.so.2.1, not libpq.so.2.  And I was
right, too :-), in that it was the -soname switch, which essentially seems
to say "If you link with me, record that fact that I'm really <soname>."

If you want to fix this in the RPMs, do something along the following
lines (manually simulated patch) in Makefile.shlib:

 ifeq ($(PORTNAME), linux)
   install-shlib-dep     := install-shlib
   shlib                 := lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION)
-  LDFLAGS_SL            := -Bdynamic -shared -soname $(shlib)
+  LDFLAGS_SL            := -Bdynamic -shared -soname lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION)
   LDFLAGS_ODBC          := -Bsymbolic -lc -lm
   SHLIB_LINK            += -lc
   CFLAGS                        += $(CFLAGS_SL)
 endif

Apps linked against the old libraries will not be fixed until relinked.

--
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/

Peter Eisentraut wrote:
> I've found the problem.  Trond was right, it was the fact that the
> programs are linked against libpq.so.2.1, not libpq.so.2.  And I was
> right, too :-), in that it was the -soname switch, which essentially seems
> to say "If you link with me, record that fact that I'm really <soname>."

There are two problems here, not just the one.  This is the one
problem.  The other is that _existing_ RPM packaged apps still need
support -- even though they were linked against the full soname.

> If you want to fix this in the RPMs, do something along the following
> lines (manually simulated patch) in Makefile.shlib:

That is useful information.  Thanks.

> Apps linked against the old libraries will not be fixed until relinked.

Or until the RPM's supply 'stop-gap' symlinks to help existing packages.

I'll implement both, as they solve two sides of the same problem.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11