ID: 21973
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Compile Failure
Operating System: Solaris 8
PHP Version: 4.3.0
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[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?
------------------------------------------------------------------------
[2003-01-30 18:42:42] [EMAIL PROTECTED]
./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
