There are a number of places in the configure file for PHP in which
the order of directories to be searched seems backward.

If I run configure with the flag

   --with-jpeg-dir=shared,/usr/freeware/

it seems to me that I should expect my stated directory to be searched
prior to any other directory for libjpeg.so.  The reality in configure
is instead:

   
% awk 'NR==25549, NR=25573' configure

if test -n "for the location of libjpeg"; then
  echo "$as_me:25551: result: $ext_output" >&5
echo "${ECHO_T}$ext_output" >&6
fi

  if test "$PHP_JPEG_DIR" != "no"; then

    for i in /usr /usr/local $PHP_JPEG_DIR; do
      test -f $i/lib/libjpeg.$SHLIB_SUFFIX_NAME -o -f $i/lib/libjpeg.a && 
GD_JPEG_DIR=$i
    done

    if test -z "$GD_JPEG_DIR"; then
      { { echo "$as_me:25562: error: libjpeg.(a|so) not found." >&5
echo "$as_me: error: libjpeg.(a|so) not found." >&2;}
   { (exit 1); exit 1; }; }
    fi

  save_old_LDFLAGS=$LDFLAGS
  LDFLAGS="
      -L$GD_JPEG_DIR/lib
     $LDFLAGS"
  echo "$as_me:25571: checking for jpeg_read_header in -ljpeg" >&5
echo $ECHO_N "checking for jpeg_read_header in -ljpeg... $ECHO_C" >&6
if test "${ac_cv_lib_jpeg_jpeg_read_header+set}" = set; then



So in the "for i" loop in line 25557, the directories /usr and
/usr/local will have their lib subdirectories checked *before* the
stated location.

This seems like a bad idea to me: if I wanted the standard directories
to be used/checked, I would have used --with-jpeg-dir=shared without
giving it a directory.

I find this structure in at least the following lines in configure
for PHP 4.2.0:

12459:    for i in /usr/local /usr $PHP_ZLIB_DIR; do
15508:  for i in /usr/local/lib /usr/lib $PHP_CRACK/lib $PHP_CRACK/cracklib; do
15512:  for i in /usr/local/include /usr/include $PHP_CRACK/include 
$PHP_CRACK/cracklib; do
17067:  for i in /usr/local /usr $PHP_CYBERMUT; do
17478:  for i in /usr /usr/local $PHP_CYRUS; do
23803:  for i in /usr /usr/local $PHP_FDFTK; do
25557:    for i in /usr /usr/local $PHP_JPEG_DIR; do
25770:    for i in /usr /usr/local $PHP_PNG_DIR; do
26073:    for i in /usr /usr/local /usr/X11R6 $PHP_XPM_DIR; do
26369:    for i in /usr /usr/local $PHP_FREETYPE_DIR; do
26556:        for i in /usr /usr/local $PHP_TTF; do
26743:    for i in /usr /usr/local $PHP_T1LIB; do
28314:  for i in /usr /usr/local $PHP_GETTEXT; do
29057:  for i in /usr/local /usr $PHP_GMP; do
30903:    for i in /usr/local /usr $PHP_IMAP; do
36297:  for i in /usr/local /usr $PHP_MCRYPT; do
37286:  for i in /usr/local /usr /opt/mhash $PHP_MHASH; do
51461:  for i in /usr/local /usr $PHP_OVRIMOS; do
54173:  for i in /usr/local /usr $PHP_PFPRO; do
57799:  for i in /usr/local /usr $PHP_READLINE; do
58628:  for i in /usr/local /usr $PHP_LIBEDIT; do
59934:  for i in /usr/local /usr $PHP_MM; do
65351:  for i in /usr/include/vpopmail /usr/include /usr ~vpopmail /home/vpopmail 
/home/popmail /var/qmail/vpopmail /var/qmail/popmail $PHP_VPOPMAIL; do
67262:  for i in /usr /usr/local $PHP_EXPAT_DIR $XMLRPC_DIR; do


IMHO this should be fixed, but I'm not quite sure it really qualifies
as a bug.

I won't even go into the headache I have given the assumption that
all libraries are in "lib" subdirectories; I'll allow that SGI's
"{lib,lib32,lib64}" subdirectory structure is a peculiarity that the
PHP developers might not have the cycles to care about.

If there *is* interest among the people who handle the configure
script on how to handle the various ABI choices IRIX presents, please
let me know, and we can discuss it outside the mailing list.

Also, if I should file this as a bug, please let me know.

regards,

--
Steve Crockett                | Team Lead--Energy/Chem/Bio Applications
SGI                           | Industry/Vertical Apps Engineering
11490 Westheimer Rd, Ste. 100 | e-mail: [EMAIL PROTECTED]
Houston, TX  77077            | phone: (281) 493-8349

-- 
PHP Install Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to