#20268 [Com]: 64-bit PHP 4.3 (extensive long vs int problems)

ID: 20268 Comment by: j-devenish at users dot sourceforge dot net Reported By: bdabney at dallasnews dot com Status: Critical Bug Type: Scripting Engine problem Operating System: any 64bit PHP Version: 4CVS-2002-11-05 New Comment: Although the original title of this bug was something to do with the CLI crashing during the installation process, the title is now 64-bit PHP 4.3. Regarding the status of 4.3.2RC1, some known problems (not new ones) are: - ./configure wants to compare hard-coded paths when finding some module libraries, rather than testing the compiler and linker themselves. This affects RedHat and SUSE Linux as well as Solaris, at least. - test cases have flaws that cause them to fail on LP64 systems although the failures aren't necessarily caused by any 64-bit problems in the code. This affects Solaris, at least. - various int/void* confusion (crash-causing). This affects Solaris, at least. These have been reported in the bug system and discussed on php-dev (and php-internals and php-qa). Although it was along time coming, some partial fixes were applied between 4.3.0 and 4.3.1RC1. Previous Comments: ------------------------------------------------------------------------ [2003-03-12 02:08:11] j-devenish at users dot sourceforge dot net FWIW, I installed a "Stable (4.3.x-dev)" snapshot! After ./configure modifications (relating to hard-coded library paths -- that affects 64-bit RedHat, too, so maybe it will get fixed) it compiled and installed without crashing. Importantly, this out-of-the-box PHP actually serves files without crashing (though I get compile warnings regarding ostensibly non 64 bit-clean code). One odd thing though: Apache reports that it is running 4.3.0-pre2. In contrast, Apache reports 4.3.2-dev when I have my php4 (PHP_4_3) checkout installed. After modifying the Makefile to run the 'test' target, that does something, too. It results in a few core dumps, and a few tests still assume that values are limited to 32-bit precision, but 4.3.2 is still a step up for anyone who hasn't been able to use PHP 4.3 yet. ------------------------------------------------------------------------ [2003-03-10 08:56:43] sniper@php.net Most, if not all issues should now be fixed. Please give the latest stable snapshot a go. (http://snaps.php.net/) ------------------------------------------------------------------------ [2003-03-04 19:51:26] sniper@php.net Need to be addressed before 4.3.2 goes out the door. ------------------------------------------------------------------------ [2003-02-23 04:36:04] sniper@php.net http://news.php.net/article.php?group=php.bugs&article=24417 http://news.php.net/article.php?group=php.bugs&article=24418 ------------------------------------------------------------------------ [2003-02-23 03:44:18] j-devenish at users dot sourceforge dot net Sigh. Since my entire post of 10/11 Nov has been deleted, and I did not receive an e-mail copy of my post via the bug submission system, I have no record of what I said. Presumably I stated that I, too, had encountered the problem, that I couldn't even install PHP 4.3, that it was due to int/long size mismatches on LP64 platforms, and then indicated the strategy I had used to work around it (via patches). I posted patches and test result information (for HEAD of the day and also for 4.3.0pre2) to php-dev on 11 November 2002. Thread subject was "64-bit PHP 4.3 (extensive long vs int problems)". Those patches are now out of date because (on the downside) further int/long problems have crept in and (on the upside) some test cases have been improved. ------------------------------------------------------------------------ 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/20268 -- Edit this bug report at http://bugs.php.net/?id=20268&edit=1