Re: libpq.so.2.0 problem

Поиск
Список
Период
Сортировка
От Lamar Owen
Тема Re: libpq.so.2.0 problem
Дата
Msg-id 3A08464A.7F1149BA@wgcr.org
обсуждение исходный текст
Ответ на libpq.so.2.0 problem  (James Hall <James.Hall@RadioShack.com>)
Ответы Re: libpq.so.2.0 problem  (Peter Eisentraut <peter_e@gmx.net>)
Список 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 по дате отправления:

Предыдущее
От: "Edward Q. Bridges"
Дата:
Сообщение: linker (ld2/dllwrap) error for PL/Perl using Cygwin port
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: libpq.so.2.0 problem