[2006-12-20 09:12 UTC] gabriel at oxeva dot fr

Hello again,

Thanks for the patch. I actually use autoconf version 2.61. This patch has corrected the bug related to the man path, but CASE 2 and 3 are not completely solved : the include_path in the PHP binary is still ".:${prefix}/share/pear" (with ${prefix} not expanded), and pear installs itslef in /usr/pear instead of /usr/share/pear as is it stated in the GNU layout.

 [2006-12-20 11:54 UTC] tony2001@php.net

Ok, I updated the patch, it should fix PEAR install path now.
Though I can't see any problems with include_path:
# sapi/cli/php -i | grep include_path
include_path => .:/tmp/php/share/pear => .:/tmp/php/share/pear

 [2006-12-20 17:09 UTC] gabriel at oxeva dot fr

so i applied the patch, ./buildconf --force again, then configure and make and make install
man paths OK, pear path OK.
but my sapi/cli/php -i give this output :
# sapi/cli/php -i | grep include_path
include_path => .:${prefix}/share/pear => .:${prefix}/share/pear

the ${prefix} looks like a variable that is not replaced (expanded) in main/build-defs.h line 81:
#define PHP_INCLUDE_PATH        ".:${prefix}/share/pear"

 [2006-12-20 17:52 UTC] tony2001@php.net

Sounds very weird to me and I'm unable to reproduce it using autoconf 2.61.

 [2006-12-20 22:56 UTC] gabriel at oxeva dot fr

After a fresh new compilation, the problem is still here.
Following are the details about my build process :
- source extraction
- last patch about the autoconf bug applied
- ./buildconf --force
- configure. The exact configure line is : 
CFLAGS='-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' \
CC='gcc -m32' \
'./configure' \
'--prefix=/usr' \
'--sysconfdir=/etc/php' \
'--disable-cgi' \
'--with-exec-dir=/bin' \
'--with-layout=GNU' \
'--enable-sigchild' \
'--disable-rpath' \
'--disable-short-tags' \
'--disable-all' \
'--enable-libxml' \
'--with-openssl' \
'--with-pcre-regex' \
'--with-zlib' \
'--with-bz2' \
'--with-curl' \
'--with-curlwrappers' \
'--enable-dba' \
'--with-inifile' \
'--enable-dom' \
'--enable-ftp' \
'--with-gd' \
'--with-freetype-dir' \
'--enable-gd-native-ttf' \
'--with-iconv' \
'--enable-mbstring' \
'--with-mcrypt' \
'--with-mysqli' \
'--with-ncurses' \
'--enable-pcntl' \
'--enable-posix' \
'--with-readline' \
'--disable-reflection' \
'--enable-simplexml' \
'--with-snmp' \
'--enable-soap' \
'--enable-sockets' \
'--enable-xml' \
'--enable-xmlreader' \
'--enable-xmlwriter' \
'--enable-zip' \
'--with-pear' \
'--enable-memory-limit' \
'--enable-zend-multibyte' \
'--with-pic' \

I've shortened it in this bug report for clarity.

- then make (GNU version 3.81)
- after make, testing the include path :
# sapi/cli/php -i | grep include_path
include_path => .:${prefix}/share/pear => .:${prefix}/share/pear

maybe it's related to another configure option ? The full option list is provided above.

Any ideas ?

 [2006-12-21 14:33 UTC] tony2001@php.net

Please try to reduce the configure line to the minimal possible.

 [2006-12-21 16:13 UTC] gabriel at oxeva dot fr

I have tested other case with a minimal configure line :
./configure --prefix=/usr --sysconfdir=/etc/php --with-layout=GNU

When using the included "configure" script, the include_path is set properly (.:/usr/share/pear), but when using a rebuilt configure script (with ./buildconf --force; to make it effective, you need to delete the configure script then type ./buildconf --force), the include_path is set to .:${prefix}/share/pear.

The buildconf output is following :
# ./buildconf --force
Forcing buildconf
using default Zend directory
buildconf: checking installation...
buildconf: autoconf version 2.61 (ok)
buildconf: Your version of autoconf likely contains buggy cache code.
           Running cvsclean for you.
           To avoid this, install autoconf-2.13.
rebuilding configure
aclocal.m4:2017: PHP_PROG_LEX is expanded from...
rebuilding main/php_config.h.in
autoheader: WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot'
autoheader: WARNING: and `config.h.top', to define templates for `config.h.in'
autoheader: WARNING: is deprecated and discouraged.
autoheader:
autoheader: WARNING: Using the third argument of `AC_DEFINE' and
autoheader: WARNING: `AC_DEFINE_UNQUOTED' allows one to define a template without
autoheader: WARNING: `acconfig.h':
autoheader:
autoheader: WARNING:   AC_DEFINE([NEED_FUNC_MAIN], 1,
autoheader:             [Define if a function `main' is needed.])
autoheader:
autoheader: WARNING: More sophisticated templates can also be produced, see the
autoheader: WARNING: documentation.
aclocal.m4:2017: PHP_PROG_LEX is expanded from...

I need to use the buildconf to add some extensions statically into php (APC and memcache for example)

 [2006-12-22 15:41 UTC] tony2001@php.net

Where did you get this particular autoconf and did you try to build it from sources?
A configure script which is unable to set the value of ${prefix} seems like an autoconf issue to me and I'm unable to reproduce it with autoconf 2.61 built from vanilla sources.

 [2006-12-22 18:44 UTC] gabriel at oxeva dot fr

My autoconf is 2.61 and built from vanilla sources too.
What are the possible dependencies linked to autoconf which might cause this bug ?

I tried running configure with autoconf 2.60 and I have the problem too. Only from autoconf 2.59 the problem seems to be solved.

What I don't understand is how you can build properly the configure script with autconf 2.61 ?

If this can be useful, my libtool is version 1.5.22. What are the other tools versions which can play a role in the build process ?

Now I'm not sure if the include_path issue is from my tools or a small bug/typo in the *.in files from the PHP source. We need to know where does this bug comes from to report the bug to the right person :)

 [2006-12-22 18:53 UTC] tony2001@php.net

>What I don't understand is how you can build properly the
>configure script with autconf 2.61 ?

Well, I don't understand how it is possible not to build it, because there are these lines in configure.in.

EXPANDED_PEAR_INSTALLDIR=`eval echo $PEAR_INSTALLDIR`
INCLUDE_PATH=.:$EXPANDED_PEAR_INSTALLDIR

and $prefix is defined just before these lines.

So the result you get looks like 2x2=5 to me.

 [2006-12-22 20:23 UTC] gabriel at oxeva dot fr

Thanks for giving me some clues about where to look for a bug. I think i have found it : this is related to the $datarootdir variable. Here is my debug with some "echo" to see how the variable expansion is done (this is done in reverse order):
--- line ~ 134948 : EXPANDED_PEAR_INSTALLDIR=`eval echo $PEAR_INSTALLDIR`
echo $EXPANDED_PEAR_INSTALLDIR outputs "${prefix}/share/pear"

--- now we look at line ~131622 : 
PEAR_INSTALLDIR=$datadir/pear which gives:

echo $PEAR_INSTALLDIR outputs "${datarootdir}/pear"

--- one level up, line ~1011: datadir='${datarootdir}'

We clearly see a nested variable expansion case which can't be expanded with 1 pass.

The line numbers may not match, as my configure script may differs from yours since it's auto-generated.

Replacing "GNU) PEAR_INSTALLDIR=$datadir/pear;;"
 in configure.in line 984 by "GNU) PEAR_INSTALLDIR=$datarootdir/pear;;"

then ./buildconf seems to correct the problem. But some regression tests with older autoconf might be needed.

There is definitely something weird with this "datarootdir" thing : having datadir and datarootdir variable seems ambiguous and maybe redundant ?

 [2006-12-25 15:12 UTC] gabriel at oxeva dot fr

It works ! And the other install paths are not mangled with this method. One remaining question is : Is this change backward compatible with autoconf <= 2.6x ?

 [2006-12-25 15:43 UTC] tony2001@php.net

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

>Is this change backward compatible with autoconf <= 2.6x ?

As long as they do not use $dataroodir for some other purposes (which is the case at the moment) - yes, it's backward compatible.