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

go to bug id or search bugs for

Bug #50596 File in Wrong Format errors
Submitted: 2009-12-28 20:26 UTC Modified: 2009-12-29 19:28 UTC
From: Steve dot Cleveland at orst dot edu Assigned:
Status: Closed Package: Compile Failure
PHP Version: 5.2.12 OS: RHEL5.4 64bit
Private report: No CVE-ID: None
View Developer Edit
 [2009-12-28 20:26 UTC] Steve dot Cleveland at orst dot edu 
Description:
------------
Starting with PHP 5.2.12, the final part of the 'make' process fails.  It appears if a system has both 32bit and 64bit libraries, building the apache1 module tries to link to the 32bit library and fails with "File in wrong format".

The issue doesn't happen with the CGI/CLI versions.

The apache version is 1.3.41

Reproduce code:
---------------
# locate libdb-4.3.so
/lib/libdb-4.3.so
/lib64/libdb-4.3.so
/usr/lib/libdb-4.3.so
/usr/lib64/libdb-4.3.so

# rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n" db4
db4-4.3.29-10.el5.x86_64
db4-4.3.29-10.el5.i386

./configure --enable-dba --with-db4 --with-apxs=/private/httpd/bin/apxs
make

Expected result:
----------------
successful build

Actual result:
--------------
/usr/bin/ld: skipping incompatible /usr/lib/libcrypt.so when searching for -lcrypt
/usr/bin/ld: skipping incompatible /usr/lib/libcrypt.a when searching for -lcrypt
/usr/bin/ld: skipping incompatible /usr/lib/libcrypt.so when searching for -lcrypt
/usr/bin/ld: skipping incompatible /usr/lib/libcrypt.a when searching for -lcrypt
/usr/bin/ld: skipping incompatible /usr/lib/librt.so when searching for -lrt
/usr/bin/ld: skipping incompatible /usr/lib/librt.a when searching for -lrt
/usr/lib/libdb-4.3.so: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
make: *** [libphp5.la] Error 1

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-12-28 20:29 UTC] Steve dot Cleveland at orst dot edu 
Sorry, forgot to mention that the compile works fine on 5.2.11 and previous.
 [2009-12-28 21:04 UTC] Steve dot Cleveland at orst dot edu 
I also get the same error with libltdl.so and the --with-mcrypt option:

# rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n" mcrypt
mcrypt-2.6.4-3.el5.i386
mcrypt-2.6.4-3.el5.x86_64

# rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n" libtool-ltdl
libtool-ltdl-1.5.22-7.el5_4.x86_64
libtool-ltdl-1.5.22-7.el5_4.i386

# locate libltdl.so
/usr/lib/libltdl.so
/usr/lib/libltdl.so.3
/usr/lib/libltdl.so.3.1.4
/usr/lib64/libltdl.so
/usr/lib64/libltdl.so.3
/usr/lib64/libltdl.so.3.1.4

./configure --with-apxs=/private/httpd/bin/apxs --with-mcrypt
make

...
 sapi/apache/mod_php5.lo sapi/apache/php_apache.lo main/internal_functions.lo -lcrypt -lcrypt -lrt -lmcrypt -lltdl -lresolv -lm -ldl -lnsl -lxml2 -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lcrypt -lxml2 -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lcrypt  -o libphp5.la
/usr/bin/ld: skipping incompatible /usr/lib/libcrypt.so when searching for -lcrypt
/usr/bin/ld: skipping incompatible /usr/lib/libcrypt.a when searching for -lcrypt
/usr/bin/ld: skipping incompatible /usr/lib/libcrypt.so when searching for -lcrypt
/usr/bin/ld: skipping incompatible /usr/lib/libcrypt.a when searching for -lcrypt
/usr/bin/ld: skipping incompatible /usr/lib/librt.so when searching for -lrt
/usr/bin/ld: skipping incompatible /usr/lib/librt.a when searching for -lrt
/usr/bin/ld: skipping incompatible /usr/lib/libmcrypt.so when searching for -lmcrypt
/usr/bin/ld: skipping incompatible /usr/lib/libmcrypt.a when searching for -lmcrypt
/usr/lib/libltdl.so: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
make: *** [libphp5.la] Error 1
 [2009-12-29 10:39 UTC] jani@php.net 
Please try using this snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

I'm pretty sure this is fixed in the repo.
 [2009-12-29 16:43 UTC] Steve dot Cleveland at orst dot edu 
That seemed to fix it.  Thanks!
 [2009-12-29 19:28 UTC] jani@php.net 
Yes, it was one bad patch that seemed innocent at the time it was committed.. :)
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Wed Jul 16 20:01:32 2025 UTC