Bug 413351 - yum package for postgresql-libs.x86_64 needs symlink
yum package for postgresql-libs.x86_64 needs symlink
Product: Fedora
Classification: Fedora
Component: postgresql (Show other bugs)
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Tom Lane
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-12-05 22:14 EST by Chad
Modified: 2013-07-02 23:15 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-04-25 00:54:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Chad 2007-12-05 22:14:09 EST
Wed Dec  5 18:09:30 MST 2007
Configure of slony fails,
 configure: error: Your version of libpq doesn't have PQunescapeBytea
 this means that your version of PostgreSQL is lower than 7.3
 and thus not supported by Slony-I.

I believe this is because configure thinks it found libpq in
/usr/lib, but since the PostgreSQL we're running is the x86_64
version it should be looking in /usr/lib64.  Let's see if we can
force that.

Should be able to use
with configure, but doesn't seem to work.  We know the symbol is in
  cd /usr/lib64
  nm -D libpq.so.5 | grep PQunescapeBytea
    00000033d680af00 T PQunescapeBytea

Wed Dec  5 19:38:31 MST 2007
Ok, here's the deal.  configure is looking for that symbol by
compiling a little program that calls for it, and checking if the 
compile succeeds.  On the gcc command line it uses -lpq to search
for the library.  On our Fedora 7, the default behavior is to build
x86_64 (64-bit) programs, which means the configuration test program
should be linked against the libraries in /usr/lib64 instead of
/usr/lib.  The linker tries to do that, looking for
"/usr/lib64/libpq.so", but that doesn't exist.  There is a
libpq.so.5 and a libpq.so.5.0.  I believe the Fedora
postgresql-libs.x86_64 package is missing a symlink
/usr/lib64/libpq.so -> libpq.so.5.0

We prove it by extracting the conftest.c program configure generated
from the config.log, compiling it (gcc -c conftest.c) and then
linking it using the path to the library rather than -lpq (gcc -o
conftest conftest.o /usr/lib64/libpq.so.5.0).  That works.  So the
error message is misleading.  The compile of the test program failed
because the linker couldn't find the right library, not because the
library didn't contain the needed routine.
Comment 1 Tom Lane 2007-12-06 01:33:27 EST
That symlink does exist, in the postgresql-devel package, which is where it belongs per longstanding 
conventions.  I think the real problem here is that the slony package you're using fails to BuildRequire 
postgresql-devel.  Please confirm ...
Comment 2 Chad 2007-12-06 23:50:50 EST
grep BuildRequires postgresql-slony1.spec
BuildRequires:  postgresql-devel, postgresql-server, initscripts
Comment 3 Tom Lane 2007-12-07 00:31:28 EST
Hmm ... well, mere inspection proves that the x86_64 postgresql-devel RPM does contain

lrwxrwxrwx   1 root     root           12 Feb 14  2007 ./usr/lib64/libpq.so -> libpq.so.5.0

so what I am wondering now is if you have the i386 postgresql-devel RPM installed, but not the other 
one.  If so, seems like this would be an RPM bug or misfeature to accept the wrong-width RPM as 
satisfying the BuildRequires.
Comment 4 Chad 2007-12-07 15:07:39 EST
toor@lnx1[postgresql-slony1-1.2.12] yum list installed postgresql-devel
Installed Packages
postgresql-devel.x86_64                  8.2.5-1.fc7            installed       
postgresql-devel.i386                    8.2.5-1.fc7            installed       
Comment 5 Tom Lane 2007-12-07 19:18:25 EST
You should most certainly have /usr/lib64/libpq.so then.  What does rpm -V say about those two 
Comment 6 Brian Powell 2008-04-25 00:54:07 EDT
The information we've requested above is required in order
to review this problem report further and diagnose/fix the
issue if it is still present.  Since there have not been any
updates to the report since thirty (30) days or more since we
requested additional information, we're assuming the problem
is either no longer present in the current Fedora release, or
that there is no longer any interest in tracking the problem.

Setting status to "CLOSED INSUFFICIENT_DATA".  If you still
experience this problem after updating to our latest Fedora
release and can provide the information previously requested, 
please feel free to reopen the bug report.

Thank you in advance.

Note that maintenance for Fedora 7 will end 30 days after the GA of Fedora 9.

Note You need to log in before you can comment on or make changes to this bug.