#19314 [Opn->Csd]: unable to startup Apache (undefined symbol)

ID: 19314 Updated by: sniper@php.net Reported By: pitrou@free.fr -Status: Open +Status: Closed Bug Type: Apache related Operating System: Linux 2.4.19 PHP Version: 4.2.3 New Comment: 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 Previous Comments: ------------------------------------------------------------------------ [2002-09-10 04:57:57] pitrou@free.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-09 17:00:43] 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-09 16:40:16] pitrou@free.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 14:55:06] 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 11:42:11] pitrou@free.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. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/19314 -- Edit this bug report at http://bugs.php.net/?id=19314&edit=1