ID: 39890 Updated by: [EMAIL PROTECTED] Reported By: gabriel at oxeva dot fr -Status: Open +Status: Closed Bug Type: *Compile Issues Operating System: Linux 2.6 PHP Version: 5.2.0 New Comment:
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. Previous Comments: ------------------------------------------------------------------------ [2006-12-25 15:12:05] 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 12:00:03] [EMAIL PROTECTED] 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-22 20:23:03] 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-22 18:53:58] [EMAIL PROTECTED] >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 18:44:15] 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 :) ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/39890 -- Edit this bug report at http://bugs.php.net/?id=39890&edit=1
