php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #19314 unable to startup Apache (undefined symbol)
Submitted: 2002-09-09 08:05 UTC Modified: 2002-09-10 09:57 UTC
From: pitrou at free dot fr Assigned:
Status: Closed Package: Apache related
PHP Version: 4.2.3 OS: Linux 2.4.19
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: pitrou at free dot fr
New email:
PHP Version: OS:

 

 [2002-09-09 08:05 UTC] pitrou at free dot fr
Hello,

I've tried to upgrade from 4.0.6 to 4.2.3, both versions
compiled from source. Although I've used the same options
for 4.2.3 as for 4.0.6, when I try to restart Apache I
have an error message. It seems it doesn't link to the
needed extension libs.

# apachectl configtest
Syntax error on line 182 of /usr/local/apache/conf/httpd.conf:
Cannot load /usr/local/apache/libexec/libphp4.so into server: /usr/local/apache/libexec/libphp4.so: undefined symbol: gdImagePngCtx

Here is the configure command :

./configure --with-apxs \
        --with-mysql=/usr/local \
        --with-bz2 \
        --with-zlib \
        --with-gd \


If I remove --with-gd, I have a similar error message :

# apachectl configtest
Syntax error on line 182 of /usr/local/apache/conf/httpd.conf:
Cannot load /usr/local/apache/libexec/libphp4.so into server: /usr/local/apache/libexec/libphp4.so: undefined symbol: uncompress

So it is not a problem with GD but rather with the way
PHP loads extensions. Is there anything I overlooked in
the build/configuration process ? Or is it really a bug ?


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-09-09 08:12 UTC] sniper@php.net
You propably don't have /usr/local/lib in /etc/ld.so.conf ?
If not, add it and run /sbin/ldconfig and it should all be okay then..

 [2002-09-09 08:26 UTC] pitrou at free dot fr
Well, after adding /usr/local/lib and doing ldconfig, I still
get the error (which is in fact normal as /usr/local/lib
is almost empty - for instance libgd.so is in /usr/lib which
is already mentioned in /etc/ld.so.conf).

A strange thing is that php-4.0.6 (compiled on the same 
machine with the same configure options) has no problems
at all.

Also, please note that Apache (version 1.3.26, BTW) is 
compiled with SSL support.
 [2002-09-09 10:49 UTC] sniper@php.net
If you do 'ldd libphp4.so' is there libz in the listing?
(that's the library for uncompress)

And about the GD problems..are you sure you don't have
different versions of GD installed in your system?

 [2002-09-09 11:04 UTC] pitrou at free dot fr
Indeed you've hit the problem.

# ldd php-4.0.6/.libs/libphp4.so
        libpam.so.0 => /lib/libpam.so.0 (0x4011c000)
        libdl.so.2 => /lib/libdl.so.2 (0x40124000)
        libmysqlclient.so.10 => /usr/lib/libmysqlclient.so.10 (0x40128000)
        libz.so.1 => /usr/lib/libz.so.1 (0x40159000)
        libgd.so.1.8 => /usr/lib/libgd.so.1.8 (0x40168000)
        libbz2.so.1 => /usr/lib/libbz2.so.1 (0x4019b000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x401ab000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x401d8000)
        libm.so.6 => /lib/libm.so.6 (0x401ea000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x4020c000)
        libc.so.6 => /lib/libc.so.6 (0x40224000)
        libttf.so.2 => /usr/lib/libttf.so.2 (0x40359000)
        libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40383000)
        libpng.so.2 => /usr/lib/libpng.so.2 (0x403a2000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

# ldd php-4.2.3/.libs/libphp4.so
        libc.so.6 => /lib/libc.so.6 (0x40127000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

It seems 4.2.3 doesn't link against anything.... Why ?
 [2002-09-09 11:23 UTC] sniper@php.net
What is the result of the ldd if you leave out --with-gd ?
(and do this with clean sources)

 [2002-09-09 11:42 UTC] pitrou at free dot fr
Indeed ;)

# ldd .libs/libphp4.so
        libdl.so.2 => /lib/libdl.so.2 (0x4011c000)
        libpam.so.0 => /lib/libpam.so.0 (0x40120000)
        libmysqlclient.so.10 => /usr/local/lib/mysql/libmysqlclient.so.10 (0x40128000)
        libbz2.so.1 => /usr/lib/libbz2.so.1 (0x40144000)
        libz.so.1 => /usr/lib/libz.so.1 (0x40155000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x40163000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x40190000)
        libm.so.6 => /lib/libm.so.6 (0x401a2000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x401c4000)
        libc.so.6 => /lib/libc.so.6 (0x401db000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

Then if I re-start from clean sources and --with-gd, I get
configure errors due to conflicting versions of gd. I 
correct the libgd.so symlink to the old version (1.8.3)
and restart configure, compile and install, and everything
is fine :-)

Question : why didn't the PHP build/compile process tell
me first of the error instead of letting me in such a hairy
mess ? 

Thank you for your help.
 [2002-09-09 14:55 UTC] kalowsky@php.net
How would it know?  It's just looking for libs and include files, and the first it finds is the first it uses.  Marking as bogus since this is/was a user issue.
 [2002-09-09 16:40 UTC] pitrou at free dot fr
"How would it know?  It's just looking for libs and include files, and
the first it finds is the first it uses.  Marking as bogus since this
is/was a user issue."


Please re-read the whole thing before coming to such
conclusions... There are two problems here :

- At one time, libphp4.so was created with no libraries linked to, yet no warning nor error told about it during the build process. Silent error ?! That's not a good behaviour as it's quite obvious that libphp4.so won't work without anything linked to, so why didn't the build process emit an error ? And why at first didn't it link against the proper libraries (even the most basic ones, see : only ldlinux and libc are referenced) ??

- Even more, the only reason I have installed GD 2.0 on top of GD 1.8.3 is because *it first failed with GD 1.8.3*. Which means I got the "undefined symbol" even at first when I tried with the right GD version. Which is definitely not a right behaviour either. The "undefined symbol" belonging to GD, I thought PHP's requirements for GD were higher now, so took the latest version.


The thing is there seems to be some borderline cases when the configure/build procedure does wrong things without telling the users. It's quite boring spending some hours chasing this kind of things (and I probably would have given up anyway if I hadn't got any help here), which should be fixed at first in PHP.

PHP 4.0.6 didn't have these annoyances, so there _is_ something borked here.
 [2002-09-09 17:00 UTC] sniper@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip

I'm pretty sure this is fixed in CVS..so please try the snapshot.

 [2002-09-10 04:57 UTC] pitrou at free dot fr
Hi,

With the latest snapshot : first build is ok.

# ldd .libs/libphp4.so
        libmysqlclient.so.10 => /usr/local/lib/mysql/libmysqlclient.so.10 (0x40179000)
        libgd.so.1.8 => /usr/lib/libgd.so.1.8 (0x401a0000)
        libbz2.so.1 => /usr/lib/libbz2.so.1 (0x401d3000)
        libz.so.1 => /usr/lib/libz.so.1 (0x401e3000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x401f2000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x4021f000)
        libm.so.6 => /lib/libm.so.6 (0x40231000)
        libdl.so.2 => /lib/libdl.so.2 (0x40253000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x40257000)
        libc.so.6 => /lib/libc.so.6 (0x4026e000)
        libttf.so.2 => /usr/lib/libttf.so.2 (0x403a4000)
        libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x403ce000)
        libpng.so.2 => /usr/lib/libpng.so.2 (0x403ed000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

There are errors during make install (PEAR installation
fails with "open_basedir restriction" errors), but not 
related to the bug. 

If I try 'make clean' and then reconfigure without gd,
the build seems ok too :

# ldd .libs/libphp4.so
        libdl.so.2 => /lib/libdl.so.2 (0x4011c000)
        libpam.so.0 => /lib/libpam.so.0 (0x40120000)
        libmysqlclient.so.10 => /usr/local/lib/mysql/libmysqlclient.so.10 (0x40128000)
        libbz2.so.1 => /usr/lib/libbz2.so.1 (0x40144000)
        libz.so.1 => /usr/lib/libz.so.1 (0x40155000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x40163000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x40190000)
        libm.so.6 => /lib/libm.so.6 (0x401a2000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x401c4000)
        libc.so.6 => /lib/libc.so.6 (0x401db000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

Regards

Antoine.
 [2002-09-10 09:57 UTC] sniper@php.net
Closing this then. The changes between 4.3.0 - 4.2.x are too big to be added to 4.2.x branch. 4.3.0 has also bundled GD library..which has couple of fixes that the 'official' gd 2.0.x doesn't have. And also some extra features. 

To enable it, just use this: --with-gd=php


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Dec 27 06:01:29 2024 UTC