>James, you can simply symlink libpq.so.2.0 to libpq.so.2.1 to get your
>stuff running.
That's exactly what I did and everything runs great now!
Thank you very much (Trond, Lamar) for all your help and 2 great products!
-Jim
-----Original Message-----
From: Lamar Owen [mailto:lamar.owen@wgcr.org]
Sent: Tuesday, November 07, 2000 12:14 PM
To: Trond Eivind Glomsrød
Cc: James Hall; pgsql-general@postgresql.org
Subject: Re: [GENERAL] libpq.so.2.0 problem
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
