ID: 21973
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Open
Bug Type: *Configuration Issues
Operating System: Solaris 8
PHP Version: 4.3.0
New Comment:
> 1) The patch allows to present the correct error message
> without changing anything else yet. I am working on a php
> wide patch that solves such problems generically.
The output was unchanged. Thanks for the further effort,
though.
> 2) I knew before what you are trying to. However you got a problem
> simply because you wnated to save some bytes...
I must have implied that I am doing something unique, here.
I'm not.
> Try this layout
>
> .../normal/png/lib
> .../normal/png/include
> .../sparcv9/png/lib
> .../sparcv9/png/include
[...]
> If you use the layout above you even have no need to configure any
> compiler linker configuration before calling ./configure.
Right...that's a bit of clutter and post package-install processing
that I
would rather the world avoid. You would at have to at least mention
this
workaround in the PHP release notes or documentation. And I'm not in a
position
to inform Sun, HP, and SGI that they've got it wrong and should travel
back in
time to change the course of history. Nor am I in a position to contact
all
users and ask them to change their system settings or symlink all
installed
packages to accommodate PHP. Nor am I in a position to write to all
package
maintainers and commercial software developers and inform them to
change their
releases to accommodate a different file structure. Nor am I in a
position to
write to all developers in the globe and ask them to change their
software
because PHP has shown us how it should be done.
> What is left could be the fact that you used "libpng12" and
> i am not quite sure if we want to search for all versions since
there
> should be links named libpng. whatever that point to the specific
> version (thats different from db-n where we search for a specific
> version).
libpng chooses libpng12 (as described in its docs). But I do seem to
have symlinks using the name libpng rather than libpng12, as you say.
Sorry for the confusion! My fault for not being particularly familiar
with libpng.
Anyway, in my eyes my original bug report stands, including my comment
that other configuration steps, such as for LDAP, are broken. Hmm,
looking at some live pages right now, LDAP compiled in fine with PHP
4.3.0 pre-release CVS. Although I had to patch PHP extensively to make
it install, load, and work correctly, I don't remember having to patch
anything in the configure script. Then again, my memory does have many
faults. ...pause to wait for fresh copies of PHP to run 'configure'...
Yes, 4.3.0 release seems to report an error when trying to find ldap
whereas 4.3.0 CVS (unknown date, I could find out though) seems fine.
I may have to leave this matter overnight since it is 7pm in my
timezone. (Which is extremely different to whatever timezone --
apparently not UTC -- that the bugs.php.net interface seems to use :)
Previous Comments:
------------------------------------------------------------------------
[2003-01-31 04:18:23] [EMAIL PROTECTED]
The way this works, works for 99.99% of users.
We're not going to change this.
------------------------------------------------------------------------
[2003-01-31 04:08:00] [EMAIL PROTECTED]
1) The patch allows to present the correct error message
without changing anything else yet. I am working on a php
wide patch that solves such problems generically.
2) I knew before what you are trying to. However you got a problem
simply because you wnated to save some bytes...
Try this layout
.../normal/png/lib
.../normal/png/include
.../sparcv9/png/lib
.../sparcv9/png/include
What is left could be the fact that you used "libpng12" and
i am not quite sure if we want to search for all versions since there
should be links named libpng.whatever that point to the specific
version (thats different from db-n where we search for a specific
version).
If you use the layout above you even have no need to configure any
compiler linker configuration before calling ./configure.
------------------------------------------------------------------------
[2003-01-31 03:34:09] [EMAIL PROTECTED]
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-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.
------------------------------------------------------------------------
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
