ID:               21973
 Updated by:       [EMAIL PROTECTED]
 Reported By:      j-devenish at users dot sourceforge dot net
 Status:           Assigned
 Bug Type:         Feature/Change Request
 Operating System: Solaris 8
 PHP Version:      4.3.3RC2-dev
 Assigned To:      sniper
 New Comment:

Another 64bit issue found in bug #24950 (oracle)



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

[2003-07-14 06:42:30] j-devenish at users dot sourceforge dot net

> I'll look into adding the macro to make the configure
> be a bit friendlier.

Thank you for looking into this and suggesting something that would
let
users to work around the brain-dead ./configure design. It will be
helpful if the problem and its solution are obvious to people (e.g. if
it is possible to generate good error messages).

At the time of my original submission, PHP was just using a stupid
library detection method. This was with regard to PNG and JPEG support
-- which almost all other software (maybe not xpdf -- I can't recall)
seems to be able to find by itself. Presumably this is because such
software uses the linker to carry out the tests. Perhaps PHP has some
new requirement that prevents it from carrying out a conventional
test?

It would have made more sense if PHP only fell back to its brute-force
file matching if a linker test failed. In fact, I think my solution to
PHP's behaviour was to delete out a few 'exit' statements -- no actual
practical problem existed. I think that it got worse with 4.3.2
because
the faulty configuration motif occurred multiple times within
./configure.

> Sparc64:
>
> */lib/sparcv9/

PHP seems to be in an exclusive club of software that requires this
extensive hand holding.

Problems that are not solved by this workaround:
 - PHP needs to be taught about every different distro,
 - PHP needs to be told about each different site.

For example, Solaris on UltraSPARC supports multiple ABIs (and
presumably Mac OS X and Linux now do, too). A particular *site* may
choose to compile PHP for a 32-bit OR a 64-bit ABI (or both, though
that
is only likely to occur when there are site-specific constraints that
require it). Thus PHP can't be shipped with this prior knowledge -- it
needs to be told on a site-by-site basis. In my scope of activities,
the
only other software requiring this much ABI knowledge is that which
uses
assembly code (e.g. OpenSSL).

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

[2003-07-12 23:12:51] [EMAIL PROTECTED]

We can add a new macro to the configure, which is used 
always for the direct search of a library files. Now the list of common
paths are:

/usr/local/lib /usr/lib

With 64bit linux distros:

/usr/lib/lib64/

(not sure if if e.g. /usr/local/lib64 can exist too?)

Sparc64:

*/lib/sparcv9/

I'll look into adding the macro to make the configure
be a bit friendlier. :)


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

[2003-01-31 05:28:14] [EMAIL PROTECTED]

If you want support your environment we would have to change all
configure files. We would have to change all
lines of the form .../lib/... with ../$LIB_DIR/... and
add some configure magic to determine what $LIB_DIR should be (in your
case it would be sparcv9).

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

[2003-01-31 03:34:09] j-devenish at users dot sourceforge dot net

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-30 18:42:42] j-devenish at users dot sourceforge dot net

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