Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 592789 - postgresql84 fails configure in multilib environment due to ldap issue
Summary: postgresql84 fails configure in multilib environment due to ldap issue
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: postgresql84
Version: 5.5
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Tom Lane
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-05-16 22:22 UTC by Karel Volný
Modified: 2013-07-03 03:28 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-05-16 22:45:30 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Karel Volný 2010-05-16 22:22:32 UTC
Description of problem:
trying to rebuild postgresql84 on ppc it fails like this:

...
checking whether strerror_r returns int... no
checking for ldap_bind in -lldap... yes
checking for ldap_simple_bind in -lldap_r... no
configure: error: library 'ldap_r' is required for LDAP
error: Bad exit status from /var/tmp/rpm-tmp.26188 (%build)


from the erratum:
"I'm not really sure why it's failing for you, but I'm suspicious that it's because you have both ppc and ppc64 versions of openldap installed.  That seems like it'd pose a risk of the linker picking the wrong library."

wherever the problem lies, postgresql, openldap, autotools, gcc or whatever (feel free to reassign ...), it should be fixed, as long as we pretend to support multilib installs

Comment 1 Tom Lane 2010-05-16 22:45:30 UTC
This isn't a bug.  We support multilib *installs*.  We don't promise that you can do a clean rebuild when there are multiple library versions lurking around.  That's probably impossible, and it would certainly require vastly more effort than is warranted.  If you need to do software builds on a multilib machine, there's always "mock".

A quick search for some precedents turns up bug #235445 and bug #344941; I'm sure there are more.


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