#21973 [Opn->Asn]: 'configure' script can't find libpng.(a|so), openldap, libjava...

ID: 21973 Updated by: sniper@php.net Reported By: j-devenish at users dot sourceforge dot net -Status: Open +Status: Assigned Bug Type: *Configuration Issues Operating System: Solaris 8 PHP Version: 4.3.3RC2-dev -Assigned To: +Assigned To: sniper New Comment: We can add a new macro to the configure, which is used always for the direct search of a library files. Now the list of common paths are: /usr/local/lib /usr/lib With 64bit linux distros: /usr/lib/lib64/ (not sure if if e.g. /usr/local/lib64 can exist too?) Sparc64: */lib/sparcv9/ I'll look into adding the macro to make the configure be a bit friendlier. :) Previous Comments: ------------------------------------------------------------------------ [2003-01-31 05:28:14] helly@php.net If you want support your environment we would have to change all configure files. We would have to change all lines of the form .../lib/... with ../$LIB_DIR/... and add some configure magic to determine what $LIB_DIR should be (in your case it would be sparcv9). ------------------------------------------------------------------------ [2003-01-31 03:34:09] j-devenish at users dot sourceforge dot net In response to (1): This makes no difference. I'm not sure if we're on the same planet. I'm not quite sure what the patch was meant to achieve (and thus I don't understand what I was supposed to do to take advantage of it once configure was regenerated). I think the loop that fails to find libpng is indeed the one you've provided the patch for, so you and I are possibly within the same universe. In response to (2): > Since you obviated a system immanent feature... Hey, I'm really confused now. I'm not at all sure what nuance you're implying with those words. I really don't understand why you said it at all. Can I try saying this to you: /usr/local/include/libpng/png.h (for both arch) /usr/local/include/libpng/pngconf.h (for both arch) /usr/local/lib/libpng12.so (32-bit) /usr/local/lib/sparcv9/libpng12.so (64-bit) PHP needs to use the files in /usr/local/include/libpng and /usr/local/lib/sparcv9. The library path is already known by the compiler, linker, and loader. ------------------------------------------------------------------------ [2003-01-30 18:42:42] j-devenish at users dot sourceforge dot net ./configure from the 4.3.0 release contains constructs like: for i in /usr /usr/local $PHP_PNG_DIR; do test -f $i/lib/libpng.$SHLIB_SUFFIX_NAME -o -f \ $i/lib/libpng.a && GD_PNG_DIR=$i done The 'lib/libpng.' bit is hard-coded. But my libpng is at /usr/local/lib/sparcv9/libpng.so The end of configure's output is: checking for the location of libpng... yes checking for the location of libXpm... yes checking for FreeType 1.x support... yes checking for FreeType 2... yes checking for T1lib support... yes checking whether to enable truetype string function in GD... yes checking for fabsf... no checking for floorf... no If configure fails try --with-jpeg-dir=<DIR> configure: error: libpng.(a|so) not found. as a user of PHP4, this message does not help me help myself because: - it already said it found libpng. - it says 'try --with-jpeg-dir' yet the error is for PNG. I was able to work around this by manually hacking configure on a one-off basis. However, it then can't find other libraries, like OpenLDAP, because it again has hard-coded paths. I was hoping that PHP 4.3.0 had some semblence of 64-bit clean-ness in its code after its disasterous run of pre-releases, but I can't even get that far since it won't configure under a multi-mode environment such as Solaris/UltraSPARC. Presumably it would have similar trouble with HP and SGI systems. --end-- ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=21973&edit=1