php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #32300 64bit libraries in */lib and */lib64
Submitted: 2005-03-14 14:30 UTC Modified: 2005-03-25 01:49 UTC
Votes:15
Avg. Score:4.7 ± 0.6
Reproduced:15 of 15 (100.0%)
Same Version:2 (13.3%)
Same OS:6 (40.0%)
From: axelseaa at amadmax dot com Assigned:
Status: No Feedback Package: Compile Failure
PHP Version: 5.0.3 OS: Fedora Core 3 64 Bit
Private report: No CVE-ID: None
View Developer Edit
 [2005-03-14 14:30 UTC] axelseaa at amadmax dot com 
Description:
------------
I was trying to compile PHP with ldap support on my 64bit FC3 system.  I used the stock rpm install of open ldap, so it had stuck the necessary files into /lib64 instead of /lib.

The only way i could get this to build was to hack the location in the configure script.  Is this something that can be corrected for the future?

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-03-14 14:35 UTC] axelseaa at amadmax dot com 
This problem is still apparent in 5.0.4RC1
 [2005-03-14 22:20 UTC] sniper@php.net 
Please try using this CVS snapshot:

  http://snaps.php.net/php5-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5-win32-latest.zip
 [2005-03-14 22:21 UTC] sniper@php.net 
And by using the latest HEAD (upcoming PHP 5.1) you'll have this configure option: --with-libdir=lib64
 [2005-03-14 23:55 UTC] axelseaa at amadmax dot com 
--with-libdir=lib64 works to find the openldap install, but i have mysql and postgresql compilied from source, so their lib directories are still just named lib.  So now it fails to find those.

what is the best way to get around this?
 [2005-03-16 07:49 UTC] sniper@php.net 
You should not mix 32bit libs with 64bit ones, iirc..
 [2005-03-16 13:51 UTC] axelseaa at amadmax dot com 
They are both build for 64 bit system, its just that the fedora build rpms stick the libs in the lib64 folder, where the custom compiled ones do not.
 [2005-03-16 15:26 UTC] axelseaa at amadmax dot com 
Jabber compiles get around this by offering the following configuration option: --with-extra-library-path=/usr/lib:/usr/lib64:/some/other/lib

Would something like this be doable?
 [2005-03-18 19:37 UTC] sniper@php.net 
*sigh* You can always tell in configure of those mysql and postgresql where they put the libraries..

IMO, you should always do whatever the distribution packages does: In this case: Put the 64bit libs in /lib64 !!
 [2005-03-25 01:49 UTC] sniper@php.net 
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
 [2005-04-02 07:41 UTC] darren at cpanel dot net 
This also happens on RHEL 3. The vendor installs libraries via up2date/rpms to both /usr/lib/ and /usr/lib64/ , however the php configure script (4.3.11) has $i/lib/library.ext hardcoded in, where $i=/usr/ and the library.ext we need to link against was installed by the vendor in /usr/lib64/ . A couple examples are libjpeg and libpng, both put in /usr/lib64/ (needed with the common GD support).
 [2007-03-23 17:12 UTC] rwarner at snaplogic dot org 
The problem persists.  I am having the same problem in 5.2.1 trying to configure on RedHat ES 4 x64_86.  It still looks for the LDAP libraries in /usr/lib rather than /usr/lib64 even with the appropriate flag set to configure to tell it to use /usr/lib64 for the libraries.
 [2007-07-05 21:41 UTC] public at caffeianted dot org 
Same problem here.

On CentOS 4.5 manually installing Apache 1.3.31 and PHP 4.4.2 and when I try to add --with-ldap, it needs to have --with-ldap=/usr/lib64 specified but then it can't find the ldap.h file which is located in the /usr/lib directory.  

How can I make this work?
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Fri Jan 03 00:01:29 2025 UTC