ID: 21973
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: *Configuration Issues
Operating System: Solaris 8
PHP Version: 4.3.0
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[2003-01-31 03:14:27] [EMAIL PROTECTED]
1) Please check if the following patch for ext/gd/config.m4
shows the correct message:
Index: ext/gd/config.m4
===================================================================
RCS file: /repository/php4/ext/gd/config.m4,v
retrieving revision 1.120.2.8
diff -u -r1.120.2.8 config.m4
--- ext/gd/config.m4 23 Jan 2003 06:22:42 -0000 1.120.2.8
+++ ext/gd/config.m4 31 Jan 2003 09:11:28 -0000
@@ -72,7 +72,9 @@
AC_DEFUN(PHP_GD_PNG,[
if test "$PHP_PNG_DIR" != "no"; then
- for i in /usr /usr/local $PHP_PNG_DIR; do
+ PNG_USER_DIR=$PHP_PNG_DIR
+ unset PHP_PNG_DIR
+ for i in /usr /usr/local $PNG_USER_DIR; do
test -f $i/lib/libpng.$SHLIB_SUFFIX_NAME -o -f $i/lib/libpng.a
&& GD_PNG_DIR=$i
done
2) Since you obviated a system immanent feature (libs in
x/lib and includes in x/include) you may required a link to point to
your library and includes.
------------------------------------------------------------------------
[2003-01-31 02:39:47] [EMAIL PROTECTED]
> --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.
------------------------------------------------------------------------
[2003-01-31 02:11:45] [EMAIL PROTECTED]
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] [EMAIL PROTECTED]
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] [EMAIL PROTECTED]
(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.
------------------------------------------------------------------------
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/21973
--
Edit this bug report at http://bugs.php.net/?id=21973&edit=1
