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

ID: 19314 User updated by: pitrou@free.fr Reported By: pitrou@free.fr -Status: Feedback +Status: Open Bug Type: Apache related Operating System: Linux 2.4.19 PHP Version: 4.2.3 New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [2002-09-09 11:23:52] sniper@php.net What is the result of the ldd if you leave out --with-gd ? (and do this with clean sources) ------------------------------------------------------------------------ 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