PHP5 FTBFS in Natty

[Michael Lustfield]

Binary package hint: php5

Due to a recent change in Natty, PHP5 is no longer able to be built from source. This also breaks the archive build.
checking for PCRE library location... configure: error: Could not find libpcre.(a|so) in /usr [1]

The libpcre package recently went to multiarch and this breaks the check in ./configure around line 23497.

[1] http://launchpadlibrarian.net/66946405/buildlog_ubuntu-natty-amd64.php5_5.3.5-1ubuntu4ppa1~natty_FAILEDTOBUILD.txt.gz

[Jonathan Marsden (jmarsden)]

Confirmed. Attempting to build php5 5.3.5-1ubuntu4 on Natty by running debuild in a local VM resulted in the attached script output.

[Jonathan Marsden (jmarsden)]

The way php5 does its library presence checks is unusual. Apparently someone recreated autotools functionality themselves, in a way that breaks the multiarch work being done for Natty.

In reality, noone is likely to rework an 85K (non-empty) line configure script! So a smaller cheaper fix needs to be found.

Attached are two small patches that allow the PHP ./configure script to find libpcre and libdb4 on a Natty (multiarch) machine.

Still needed are equivalent fixes for at least some of the graphics libraries... but I need some sleep :)

[Jonathan Marsden (jmarsden)]

Note that changing configure parameter --with-libdir=lib/${DEB_HOST_MULTIARCH} does not work, because this is used for finding both header files and actual libraries.

So (unless others have better ideas) it seems that patching the various config*.m4 files for each such test is the best we can do.

[Jonathan Marsden (jmarsden)]

One more, hopefully the last, multiarch-related patch is attached, for various graphics libraries.

[Jonathan Marsden (jmarsden)]

debdiff will follow once this builds and I test it a little.

[Jonathan Marsden (jmarsden)]

Ahem... spoke too soon. The configure script now runs to completion but the link step fails.

[Chuck Short (zulcss)]

Hi,

Thanks for the patch please send the debdiff anyways.

chuck

[Steve Langasek (vorlon)]

It would be best here to mirror the behavior of the compiler, and list the multiarch-qualified directory /before/ the unqualified directory.

(It's unfortunate that we don't have time to convert the entire system in one cycle; if all of PHP5's build-deps were transitioned to multiarch, we could just pass --with-libdir=lib/$(DEB_HOST_MULTIARCH).

[Steve Langasek (vorlon)]

> Ahem... spoke too soon. The configure script now runs to completion but the link step fails.

I believe that's because libgd2 needs updated to clean out its .la file. I've fixed libgd2 now and am doing a test build with your patches to see if it finishes.

[Jonathan Marsden (jmarsden)]

Ah, that would be nice --- I thought I'd missed something; if you are correct I can claim my patches are fine and libgd2 was the culprint :)

Regarding your earlier comment:

> (It's unfortunate that we don't have time to convert the entire system in one cycle;
> if all of PHP5's build-deps were transitioned to multiarch, we could just pass
> --with-libdir=lib/$(DEB_HOST_MULTIARCH).

I tried that early on. I don't think this is approach workable even in a perfect "one cycle conversion" world, because the --with-libdir option changes where .h files are looked for, as well as whe .a and .so files are looked for. Multiarch moves .a and.so files around, but (from what I have seen) leaves .h files where they were, since they do not (generally) change with CPU architechure.

[Steve Langasek (vorlon)]

On Thu, Mar 24, 2011 at 10:19:47PM -0000, Jonathan Marsden wrote:
> > (It's unfortunate that we don't have time to convert the entire system in one cycle;
> > if all of PHP5's build-deps were transitioned to multiarch, we could just pass
> > --with-libdir=lib/$(DEB_HOST_MULTIARCH).

> I tried that early on. I don't think this is approach workable even in
> a perfect "one cycle conversion" world, because the --with-libdir option
> changes where .h files are looked for, as well as whe .a and .so files
> are looked for. Multiarch moves .a and.so files around, but (from what
> I have seen) leaves .h files where they were, since they do not
> (generally) change with CPU architechure.

--with-libdir is actually documented to do exactly what we want. It appears
to be how /usr/lib64 handling is done for RH / SuSE, and it should work as
well for multiarch.

I only ran into problems when trying --with-libdir when I got to openssl
detection, since openssl has not yet been multiarched.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[Launchpad Janitor (janitor)]

This bug was fixed in the package php5 - 5.3.5-1ubuntu5

---------------
php5 (5.3.5-1ubuntu5) natty; urgency=low

  * debian/patches/temporary-path-fixes-for-multiarch.patch: as a stopgap
    for natty, patch the various config.m4 files for modules whose
    libraries have moved to the multiarch dir; we can't use --with-libdir
    yet because that requires all the build-deps to have moved. Thanks to
    Jonathan Marsden for preparing this patch. LP: #739977.
  * debian/patches/ubuntu/ubuntu-php-version.patch: drop. This is an
    autogenerated file.
 -- Steve Langasek <email address hidden> Thu, 24 Mar 2011 22:34:00 +0000