I've worked around the problem. You might decide that this was a user error.

I'm the maintainer of php in MacPorts, and we build most of the bundled extensions separately from php itself, so that they can be installed and uninstalled separately. The pdo extensions don't build out of the box because they can't find the pdo headers, because the main php ports install them in a nonstandard location (to allow multiple different php versions to be installed simultaneously). For example php56 installs them in /opt/local/include/php56/php/ext/pdo. The extension build is looking for the pdo headers in the path ext/pdo relative to the source directory, which when building the extensions separately is the extension's own directory. I've been dealing with this for the past 4 years by adding a symlink to the pdo headers installed by the php port. So for example, when building the php56 version of pdo_pgsql, I'd have MacPorts make a symlink from ext/pdo_pgsql/ext/pdo pointing to /opt/local/include/php56/php/ext/pdo. This worked with previous versions, but not version 5.6.0alpha1, because now the source directory ext/pdo contains this php_pdo_error.h header which does not get installed. On the assumption that this is intended to be a private header, I've changed my build strategy to now make the symlink from ext/pdo_pgsql/ext/pdo point to ext/pdo, and the build now succeeds.

let's see what Matteo thinks about this (as he was the person introducing php_pdo_error.h in http://git.php.net/?p=php-src.git;a=commitdiff;h=1e36e45d97da9e212b00f339c90b995908efa70c )

Nice catch!

Yes, php_pdo_error.h is supposed to be external, and that's why I moved the code away from php_pdo_int.h.

I believe I forgot to add a reference to it in config.m4/w32, but what's weird is that on my test box the header file is installed anyway.