php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #39890 GNU layout and --sysconfdir option break install and include paths
Submitted: 2006-12-19 17:22 UTC Modified: 2006-12-25 15:43 UTC
From: gabriel at oxeva dot fr Assigned:
Status: Closed Package: *Compile Issues
PHP Version: 5.2.0 OS: Linux 2.6
Private report: No CVE-ID: None
 [2006-12-19 17:22 UTC] gabriel at oxeva dot fr
Description:
------------
When compiling PHP, using the configure script with the --sysconfdir or using the GNU layout option breaks paths such as PHP_INCLUDE_PATH or PHP_SYSCONFDIR set in main/build-defs.h. It seems there is some path expansions are missing in the configure script

Reproduce code:
---------------
use the configure script with --prefix=/usr and --with-layout=GNU and/or --sysconfdir=/etc/php

some examples :
first, rebuild the configure script with ./buildconf --force
then,

CASE 1 : configure line (sysconfdir, but not the GNU layout):
./configure --prefix=/usr --disable-cgi --sysconfdir=/etc/php

CASE 2 : configure with GNU layout, but without sysconfdir :
./configure --prefix=/usr --disable-cgi --with-layout=GNU

CASE 3 : configure with GNU layout and sysconfdir :
./configure --prefix=/usr --disable-cgi --sysconfdir=/etc/php --with-layout=GNU

Expected result:
----------------
CASE 1:
- Man pages in the right place (/usr/man)

CASE 2:
- include_path : .:/usr/share/pear
- have a working --sysconfdir option

CASE 3:
- man pages in /usr/man
- pear in /usr/share/pear
- include_path : .:/usr/share/pear

Actual result:
--------------
CASE 1:
- man pages installed in /man (directly in the root filesystem!)

CASE 2:
- include_path broken : include_path => .:${prefix}/share/pear
- no option to define where to place files such as pear.conf (in sysconfdir)


CASE 3:
- man pages installed in /man
- pear installed in /pear
- include_path broken : include_path => .:${prefix}/share/pear



Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-12-20 00:00 UTC] tony2001@php.net
What version of autoconf do you use?
 [2006-12-20 00:21 UTC] tony2001@php.net
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.
 [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 12:00 UTC] tony2001@php.net
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

 [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.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Dec 07 08:01:28 2024 UTC