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

ID: 21973 User updated by: j-devenish@users.sourceforge.net Reported By: j-devenish@users.sourceforge.net -Status: Bogus +Status: Open Bug Type: Compile Failure Operating System: Solaris 8 PHP Version: 4.3.0 New Comment: > --with-png-dir[=DIR] GD: Set the path to libpng install prefix. > that means you can set your library patch as follows: > --with-png-dir=/usr/local/lib/sparcv9 That makes no observable difference. Configure still reports "checking for the location of libpng... yes" (not that I have a directory called 'yes'...) and still says "If configure fails try --with-jpeg-dir=<DIR> configure: error: libpng.(a|so) not found." (and then stops). Note that the sparcv9 path is not libpng's "install prefix", it is just the lib dir. Previous Comments: ------------------------------------------------------------------------ [2003-01-31 02:11:45] helly@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Look into ./configure --help: --with-png-dir[=DIR] GD: Set the path to libpng install prefix. that means you can set your library patch as follows: --with-png-dir=/usr/local/lib/sparcv9 But yes we could do it in another order to have more helpful error messages. ------------------------------------------------------------------------ [2003-01-31 01:39:32] derick@php.net FYI: I dont have that libpng-config thingy, and most older (7.x) RedHat versions still use libpng 1.0.x so don't assume it's available. ------------------------------------------------------------------------ [2003-01-30 20:20:04] j-devenish@users.sourceforge.net (1) png-config: > is there a config script, like png-config Aha! A file search shows libpng-config with the following usage: Usage: libpng-config [OPTION] ... Known values for OPTION are: --prefix print libpng prefix --libdir print path to directory containing library --libs print library linking information --ccopts print compiler options --cppflags print pre-processor flags --cflags print preprocessor flags, I_opts, and compiler options --I_opts print "-I" include options --L_opts print linker "-L" flags for dynamic linking --R_opts print dynamic linker "-R" or "-rpath" flags --ldopts print linker options --ldflags print linker flags (ldopts, L_opts, R_opts, and libs) --static revise subsequent outputs for static linking --help print this help and exit --version print version information This is for version 1.2.5. But I just had a look at various stable-distribution GNU Linux/Intel machines and they do not appear to have this with older libpng. (2) LDAP: Here there are issues with having so many different LDAP distributions to be compatible with. But PHP seems to ignore an existing, working path configuration and try to discover another configuration by using hard-coded filenames rather than compilation tests (leaving no diagnostic messages about why it did or didn't succeed). (3) Banter: > You make it sound like a 'why does php do this' type of problem, Yes: in the case of PNG, why does PHP do a linking check for libpng using the user's environment and system linker settings but then throw that away and use some hard-coded filename values for a file presence test as part of different half-related module instead of using the known-good values it already has? (I think that technically qualifies as a sentence ;) Perhaps it is to deal with some fringe case, so perhaps PHP could assess whether the fringe case is present before trying to compensate for it. > Think about it: if > 90% of unices put libraries in $prefix/lib In a mixed processor mode environment where there can be multiple architecture variants of libraries (e.g. one that uses the processor's preferred arch and one that uses a compatibility arch), something has to give. In Sun's case, it decided on the convention of putting different architectures into different directories, preventing files from one arch obliterating files from another. And in the end, I got PHP 4.3.0 to compile but it still thinks sizeof(int) == sizeof(long) and crashes during installation. ------------------------------------------------------------------------ [2003-01-30 19:35:26] msopacua@php.net <attitude>You make it sound like a 'why does php do this' type of problem, but think about it: if > 90% of unices put libraries in $prefix/lib, then you can just see the Sun people sitting in their offices saying: "let's make portable software sweat a little so everybody uses Solaris again". </attitude> Working towards the solution: is there a config script, like png-config, which reports how the library was installed - similar to mysql_config/curl-config/mm-config and such? If not - does this apply to all Solaris 8 installed libraries and also to headers or is this different for different packages? ------------------------------------------------------------------------ [2003-01-30 18:42:42] j-devenish@users.sourceforge.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