Same as bug #74627 - build ind Zend/strtod.c: [.....snip.....] /var/tmp/portage/php-5.0.3/work/php-5.0.3/Zend/zend_strtod.c:239: error: parse error before "uint32_t" /var/tmp/portage/php-5.0.3/work/php-5.0.3/Zend/zend_strtod.c:239: warning: no semicolon at end of struct or union /var/tmp/portage/php-5.0.3/work/php-5.0.3/Zend/zend_strtod.c:240: warning: data definition has no type or storage class /var/tmp/portage/php-5.0.3/work/php-5.0.3/Zend/zend_strtod.c:386: error: parse error before "uint32_t" /var/tmp/portage/php-5.0.3/work/php-5.0.3/Zend/zend_strtod.c:386: warning: no semicolon at end of struct or union /var/tmp/portage/php-5.0.3/work/php-5.0.3/Zend/zend_strtod.c: In function `Balloc': /var/tmp/portage/php-5.0.3/work/php-5.0.3/Zend/zend_strtod.c:405: error: dereferencing pointer to incomplete type /var/tmp/portage/php-5.0.3/work/php-5.0.3/Zend/zend_strtod.c:409: error: invalid application of `sizeof' to an incomplete type Some digging at http://bugs.php.net came up with this report: http://bugs.php.net/bug.php?id=31107 with reference to Solaris 9 (Intel) and gcc-3.4.3, and a statement that it is fixed in CVS, available in the latest snapshot. I downloaded the php5-STABLE-200501200930.tar.bz2 snapshot from http://snaps.php.net and altered the php-5.0.3 & mod_php-5.0.3 ebuilds to copy the snapshot php-5.0.3/Zend/zend_strtod.c during source unpack. Both builds completed successfully. Reproducible: Always Steps to Reproduce: 1. 2. 3. "emerge info" not available at this time. The machine is a quad-cpu E450, using keyword ~sparc, and no bleeding-edge CFLAGS. The kernel is 2.6.x and switching from linux-headers to linux26-headers made no difference to the ebuild failing...
Created attachment 49278 [details, diff] patch for php-5.0.3/Zend/strtod.c The attached patch was derived by diffing php-5.0.3/Zend/zend_strtod.c against the snapshot version in php5-STABLE-200501200930.tar.bz2 from http://snaps.php.net. With this patch, or indeed completely copying the snapshot Zend/strtod.c, the php-5.0.3 & mod_php-5.0.3 ebuild both complete successfully on ~sparc.
Sparc: can you confirm this fix solves it for you?
there is already a patched 5.0.3 of these marked ~sparc in portage. is that causing a problem for you?
Emerge wasn't applying the stdint patch, though I couldn't see why not. It turns out, after a lot more trial and error, that I had a bad flag in /etc/make.conf: ARCH="sparc64" This probably dates back to trying to switch from egcs to gcc for kernel builds. This forum post: http://forums.gentoo.org/viewtopic.php?p=132918#132918 is likely one of the reasons I had that flag in /etc/make.conf. Anyway, with that flag removed, emerge applies the stdint.diff patch and php build correctly. So, problem resolved - user error. If there was a subsequent post saying don't use ARCH="sparc64", I must have missed it...
User reported problem as fixed.
