What version of autoconf do you use?

Please check out this patch: http://tony2001.phpclub.net/dev/tmp/bug39890.diff
Apply with `patch -p0 < bug39890.diff`, run ./buildconf etc. after that. 
The patch seems to make autoconf 2.6x happy again.

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.

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

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"

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

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 ?

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

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)

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.

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 :)

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

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 ?

What if you move $datarootdir declaration before this line:
EXPANDED_PEAR_INSTALLDIR=`eval echo $PEAR_INSTALLDIR`?
Like this: http://tony2001.phpclub.net/dev/tmp/bug39890.diff

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 ?

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.