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

Edit report at http://bugs.php.net/bug.php?id=21973&edit=1 ID: 21973 Updated by: jani@php.net Reported by: j-devenish at users dot sourceforge dot net Summary: 'configure' script can't find libpng.(a|so), openldap, libjava... -Status: Assigned +Status: Closed Type: Feature/Change Request -Package: Feature/Change Request +Package: *General Issues Operating System: Solaris 8 PHP Version: 4.3.3RC2-dev -Assigned To: +Assigned To: jani Block user comment: N Private report: N New Comment: Use --with-libdir, we hold hands here. ;) Previous Comments: ------------------------------------------------------------------------ [2003-08-06 09:54:23] sniper@php.net Another 64bit issue found in bug #24950 (oracle) ------------------------------------------------------------------------ [2003-07-14 06:42:30] j-devenish at users dot sourceforge dot net > I'll look into adding the macro to make the configure > be a bit friendlier. Thank you for looking into this and suggesting something that would let users to work around the brain-dead ./configure design. It will be helpful if the problem and its solution are obvious to people (e.g. if it is possible to generate good error messages). At the time of my original submission, PHP was just using a stupid library detection method. This was with regard to PNG and JPEG support -- which almost all other software (maybe not xpdf -- I can't recall) seems to be able to find by itself. Presumably this is because such software uses the linker to carry out the tests. Perhaps PHP has some new requirement that prevents it from carrying out a conventional test? It would have made more sense if PHP only fell back to its brute-force file matching if a linker test failed. In fact, I think my solution to PHP's behaviour was to delete out a few 'exit' statements -- no actual practical problem existed. I think that it got worse with 4.3.2 because the faulty configuration motif occurred multiple times within ./configure. > Sparc64: > > */lib/sparcv9/ PHP seems to be in an exclusive club of software that requires this extensive hand holding. Problems that are not solved by this workaround: - PHP needs to be taught about every different distro, - PHP needs to be told about each different site. For example, Solaris on UltraSPARC supports multiple ABIs (and presumably Mac OS X and Linux now do, too). A particular *site* may choose to compile PHP for a 32-bit OR a 64-bit ABI (or both, though that is only likely to occur when there are site-specific constraints that require it). Thus PHP can't be shipped with this prior knowledge -- it needs to be told on a site-by-site basis. In my scope of activities, the only other software requiring this much ABI knowledge is that which uses assembly code (e.g. OpenSSL). ------------------------------------------------------------------------ [2003-07-12 23:12:51] sniper@php.net 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. :) ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ 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/bug.php?id=21973 -- Edit this bug report at http://bugs.php.net/bug.php?id=21973&edit=1