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:

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


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

[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

Reply via email to