Re: libpq.so.2.0 problem - Mailing list pgsql-general

From Lamar Owen
Subject Re: libpq.so.2.0 problem
Date
Msg-id 3A08464A.7F1149BA@wgcr.org
Whole thread Raw
In response to libpq.so.2.0 problem  (James Hall <James.Hall@RadioShack.com>)
Responses Re: libpq.so.2.0 problem
List pgsql-general
Trond Eivind Glomsrød wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > > The application itself is linked with libpq.so.2.0 instead of
> > > libpq.so.2, which would solve the problem...

> > This is a thing with the find-requires script.

> No, this wasn't at the rpm level.

I see what you're talking about, now.

Of course, this is a little different from the problem I mentioned
earlier -- this is a runtime issue, whereas the earlier was an
install-time issue. And that complicates things.  But the install-time
issue also exists -- although, even if installation is allowed, you can
still get hung up with the run-time issue.

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 consensus within the PostgreSQL developer community is that 'we
version our libs.  If an OS has a problem with that, and others do not,
then that isn't our problem.'  Source-centric, I know.  But it's just
the way it is.

The RPM distribution can get away with the copy over the symlink thanks
to the version information being stored in the rpm database.

But, no, this isn't necessarily an RPM issue per se -- it is a general
library versioning issue.

James, you can simply symlink libpq.so.2.0 to libpq.so.2.1 to get your
stuff running.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

pgsql-general by date:

Previous
From: "Edward Q. Bridges"
Date:
Subject: linker (ld2/dllwrap) error for PL/Perl using Cygwin port
Next
From: Peter Eisentraut
Date:
Subject: Re: libpq.so.2.0 problem