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
|
Список | 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 по дате отправления: