karmic: Compiling php fails with autoconf 2.64

Bug #411890 reported by dreamcat4 on 2009-08-11
20
This bug affects 2 people
Affects Status Importance Assigned to Milestone
PLD Linux
Undecided
Unassigned
php5 (Ubuntu)
Undecided
Unassigned
Declined for Karmic by Thierry Carrez

Bug Description

Binary package hint: php5

On a fresh 9.10 (karmic) system, php5 (5.2.10) source package will not compile.
./configure fails with "cat: confdefs.h: No such file or directory"

Steps:

# Install brand new Ubuntu karmic release (alpha 3)
sudo pbuilder --create --distribution karmic
dget -xu https://launchpad.net/ubuntu/karmic/+source/php5/5.2.10.dfsg.1-1ubuntu1/+files/php5_5.2.10.dfsg.1-1ubuntu1.dsc
cd php5_5.2.10.dfsg.1/
pdebuild -- --distribution karmic

cat: confdefs.h: No such file or directory
../configure: 488: ac_fn_c_try_run: not found
../configure: 488: 5: Bad file descriptor
../configure: 488: :: checking for pthreads_cflags: not found
../configure: 488: 6: Bad file descriptor

This error has been reproduced many times on the build farm, and also independently on 2 developer's machines. Build log attached.

This source package can be compiled successfully on jaunty (after resolving php5.2.10 dependencies), with no such errors. The build logs between karmic and jaunty looks almost identical.

Examination of the build area afterwards shows that the 'condefs.h' file do exist in the apache2-build diectory however, the ./configure script is a complete mess, after being regenerated with a different version of autoconf (2.64 instead of 2.13 although Jaunty also has a different autocond which is 2.63). This error appears to be caused somewhere around the 'buildconf --force' stage in the rules file. At a time when "./configure" is being regenerated.

So I compared with those older Successful build logs from the build farm. Side-by side there's only 2 lines different:

Success log:

buildconf: checking installation...
buildconf: autoconf version 2.63 (ok)
buildconf: Your version of autoconf likely contains buggy cache code.
           Running cvsclean for you.
           To avoid this, install autoconf-2.13.
rebuilding aclocal.m4
rebuilding configure
aclocal.m4:2099: PHP_PROG_LEX is expanded from...
configure.in:463: warning: AC_CACHE_VAL(have_broken_glibc_fopen_append, ...): suspicious cache-id, must contain _cv_ to be cached

Fail log:

buildconf: checking installation...
buildconf: autoconf version 2.64 (ok)
buildconf: Your version of autoconf likely contains buggy cache code.
           Running cvsclean for you.
           To avoid this, install autoconf-2.13.
rebuilding aclocal.m4
rebuilding configure
configure.in:463: warning: AC_CACHE_VAL(have_broken_glibc_fopen_append, ...): suspicious cache-id, must contain _cv_ to be cached

This package was originally build when karmic has autoconf 2.63. Now karmic is autoconf 2.64 then php5 will fail to build. (I am unsure what is the correct resolution for this.)

dreamcat4 (dreamcat4) wrote :
description: updated
dreamcat4 (dreamcat4) on 2009-08-11
description: updated
summary: - karmic: configure fails with "cat: confdefs.h: No such file or
- directory"
+ karmic: Compiling php fails with autoconf 2.64
dreamcat4 (dreamcat4) wrote :

Notifying Andrew Mitchell....

Andrew can we get some people to take a look at this? Its a stopper for [needs-packaging] php-fpm
https://bugs.launchpad.net/bugs/397721

Andreas Olsson (andol) wrote :

I can confirm this bug, based on my own experiences noted in bug #409775.

Changed in php5 (Ubuntu):
status: New → Confirmed
Stas Sușcov (sushkov) wrote :

Hi,
imho karmic is an intermediary release so we should think about pushing php 5.3.x into it.
Also having php 5.3.x in karmic, will allow us get it more stable for the next LTS.

More than this, php 5.2.9 is already in Debian testing, so moving up to 5.3.0 would be somehow synced with them.

dreamcat4 (dreamcat4) wrote :

https://launchpad.net/ubuntu/karmic/i386/autoconf

This page says:

"This version of autoconf is not compatible with scripts meant for
 Autoconf 2.13 or earlier. If you need support for such scripts,
 you must also install the autoconf2.13 package."

If you choose install autoconf2.13 package in addition to the 2.64, then the default autoconf executable(s) are changed to the 2.13 versions. The newest autoconf2.64 becomes a secondary, and accessible as 'autoconf2.64'. When you uninstall 2.13, then the 2.64 is put back as the primary again.

So perhaps autoconf2.13 can be added as a php5 build - time dependency. Needs testing.

Andreas Olsson (andol) wrote :

@dreamcat4: Thanks for doing all the research and actual thinking in this matter!

Making autoconf2.13 an explicit build dependency (instead of merely autoconf) does make php5 build nicely. I generated new source packages with this change, and built it without any trouble inside a pbuilder chroot.

The potential side effect is of course that someone unknowingly doing an "apt-get build-dep php5" might later on experience some unexpected autoconf issues.

Changed in php5 (Ubuntu):
status: Confirmed → Triaged

On Wed, Aug 12, 2009 at 8:27 AM, Andreas Olsson<email address hidden> wrote:
> autoconf) does make php5 build nicely. I generated new source packages
> with this change, and built it without any trouble inside a pbuilder
> chroot.

Well, this is fantastic. I've been puzzled and frustrated over this
error all week.
Next steps i guess we follow the https://wiki.ubuntu.com/SponsorshipProcess

> The potential side effect is of course that someone unknowingly doing an
> "apt-get build-dep php5" might later on experience some unexpected
> autoconf issues.

That concern is split to bug #412448

dreamcat4 (dreamcat4) wrote :
Andreas Olsson (andol) wrote :

Also, according to the (not entirely new) comment to http://bugs.php.net/bug.php?id=46744

Even using the SVN version of PHP autoconf 2.13 seems like the prefered choice: http://www.php.net/svn.php

Andreas Olsson (andol) wrote :

Ok, let me try again...

Also, according to the (not entirely new) comment to http://bugs.php.net/bug.php?id=46744 autoconf 2.13 it sounds as if 2.13 is the only supported version of autoconf.

Even using the SVN version of PHP autoconf 2.13 seems like the prefered choice: http://www.php.net/svn.php

dreamcat4 (dreamcat4) wrote :

If i don't misunderstand the article (http://www.php.net/svn.php), it seems they are referring to the stock GNU version of autoconf 2.13as there's no copy of autoconf on php's svn server. We should be fine using our debian autoconf2.13 package as its taken from the official GNU sources. Since you built it, then im building it too. My compile has passed the buildconf stage ok now so i think we can consider that verified.

https://launchpad.net/~dreamcat4/+archive/ppa

php5 (5.2.10.dfsg.1-1ubuntu2) karmic; urgency=low

  * debian/control: (autoconf) Update build dependancies (closes: 411890)
    - Revert to autoconf2.13, until upstream can support autoconf 2.64

 -- dreamcat four <email address hidden> Wed, 12 Aug 2009 13:10:06 +0100

dreamcat4 (dreamcat4) on 2009-08-12
tags: added: verification-done
Changed in php5 (Ubuntu):
status: Triaged → Fix Committed
Andreas Olsson (andol) wrote :

Hmm, just realized that my last sentence wasn't entirely clear. I was refering what the SVN version of PHP prefers. So yes, "our" autoconf2.13 is what I guess we should use.

Andreas Olsson (andol) wrote :

Setting status back to Triaged.

@dreamcat4: The "Fix commited" status is usually set by a developer, once they have uploaded the debdiff (No, PPA doesn't count). "In progress" is another status also usually reserved for developers.

Changed in php5 (Ubuntu):
status: Fix Committed → Triaged
James Westby (james-w) wrote :

Hi,

Why did you drop the dependency on automake1.4?

Thanks,

James

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package php5 - 5.2.10.dfsg.1-2ubuntu1

---------------
php5 (5.2.10.dfsg.1-2ubuntu1) karmic; urgency=low

  * Merge from debian unstable, remaining changes:
    - debian/control, debian/rules: Disable a few build dependencies and
      accompanying, binary packages which we do not want to support in main:
      + firebird2-dev/php5-interbase (we have a seperate php-interbase source)
      + libc-client/php5-imap (we have a seperate php-imap source)
      + libmcrypt-dev/php5-mcrypt (seperate php-mycrpt source)
      + readline support again, now that the libedit issue is fixed.
    - debian/control: Add build dependency: libdedit-dev (>= 2.9.cvs.20050518-1)
      CLI readline support.
    - debian/rules:
      - Correctly mangle PHP5_* macros for lpia
    - debian/patches/119-sybase-alias.patch:
      + Fix sybase regression since change to mssql. (LP: #240519)
    - debian/patches/fix-autoconf-ftbfs.patch:
      + Fixes FTBFS.
    - debian/control:
      + Use libdb-4.6-dev
      + Rename Vcs-Browser & Vcs-Git to XS-Original-Vcs-Browser & XS-Original-Vcs-Git (LP: #323731).
      + Use autoconf2.13 to build. Thanks to dreamcast4 (LP: #411890)

php5 (5.2.10.dfsg.1-2) unstable; urgency=low

  * Declare that PEAR replaces XML_UTIL (Closes: #534621)
  * Bump standards-version, no change needed
  * Fix an unconditional limit on dblib_driver.c (Closes: #534881)
  * Fix a segfault on exif_data_read with corrupted jpg files (Closes: #535888)
  * Recommend php5-suhosin, as suggested by Thijs (Closes: #529760)
  * Set sysconfig to /etc, to avoid getting /usr/etc in PHP_SYSCONFDIR
  * Add myself to uploaders
  * Fix the path to PEAR's config, directly in rules (Closes: #507762)

 -- Chuck Short <email address hidden> Fri, 10 Jul 2009 07:19:08 +0100

Changed in php5 (Ubuntu):
status: Triaged → Fix Released
dreamcat4 (dreamcat4) wrote :

On Fri, Aug 14, 2009 at 12:26 PM, James Westby<email address hidden> wrote:
> Why did you drop the dependency on automake1.4?

That's a rookie mistake as i had believed that autoconf2.13 depends
upon automake1.4. But automake is not a dependancy - its a
'recommends'. Thanks for picking that up.

Arkadiusz Miśkiewicz (arekm) wrote :

Most likely divert numbering conflicts with autoconf internal one. I just cooked such patch that fixes the autoconf 2.64 problem for me: http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/php/php-m4-divert.patch?rev=1.1 . Same way works for php4.

Elan Ruusamäe (glen666) on 2009-11-10
Changed in pld-linux:
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.