ID:               21973
 Updated by:       [EMAIL PROTECTED]
 Reported By:      [EMAIL PROTECTED]
 Status:           Open
-Bug Type:         Compile Failure
+Bug Type:         *Configuration Issues
 Operating System: Solaris 8
 PHP Version:      4.3.0
 New Comment:

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.


Previous Comments:
------------------------------------------------------------------------

[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.

------------------------------------------------------------------------

[2003-01-30 19:35:26] [EMAIL PROTECTED]

<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?

------------------------------------------------------------------------

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

Reply via email to