Could you post your compiler version and the output of 
'configure' ? 

adconrad@cranx:~$ gcc -v
Reading specs from /usr/lib/gcc-lib/sparc-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)

./configure output (and log) is at http://people.debian.org/~adconrad/php/config.{out,log}

Could you try and compile with gcc-3.3 ? (I'm not 
suggesting this as a fix, I'm just curious if it will work 
around the problem)  
I would do it myself if I had access to a Sparc64/linux 
machine. 
 

I'll build a Debian unstable chroot with gcc-3.3 and give it a whirl.  Of course, that'll also be using a new glibc, among other things, so it's not terribly scientific.

I could also try gcc-3.0 on a stable system and see if that makes it happy.  Either way, gcc-2.95 and glibc 2.2 is a combination that should probably be on the supported list for a while yet, I'd say.

Okay, there isn't much point in testing with gcc-3.3 on an unstable system.  I just install gcc-3.0.4 on the same stable system I was testing this bug on, and it seems to work just fine.  config.{out,log}-gcc-3.0 and build.log-gcc-3.0 at the same URL as previous logs.

So, to repeat:  This bug appears to vanish building with gcc-3.0.4 (and presumably any gcc 3.x), but manifests with gcc-2.95.

The latest snapshot didn't actually have any changes other than derick's valgrind-induced fixes, and still failed.  Of course, this is what I get for responding too quickly to the bug.  :)

I snagged your config.m4 changes from CVS, applied them, regenerated configure, and the resulting binary still segfaults with the same backtrace as before.

config.{out,log} and build.log available at the same URL as always, with a "gcc-2.95-snapshot" suffix.

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

Please try the new config.m4 
Could you try and tweak the #ifdefs if they still don't 
work, and report back here. 
 
Clearly, this is a compiler/glibc bug. Sounds like 
something you guys at Debian might wanna fix as well. 

> Please try the new config.m4 

No go.  The glibc tests appear to be incorrect.  I took them out anyway, and changed the others, as rationalised below.

> Could you try and tweak the #ifdefs if they still don't 
> work, and report back here. 

New and improved line:
-------------------------------------------------
#if (__GNUC__ == 2)&&(__GNUC_MINOR <= 96)&&defined(__sparc__)
-------------------------------------------------

1. I bumped the __GNUC_MINOR version to 96, as I will give you 99-to-1 odds the bug lasted until later pre-releases, and there are a couple of dists out there (*cough*RedHat*cough*) that actually released a stable dist based on that buggy pre-release.  I can't verify this in the GCC bug tracker right now, but given how few people would be running gcc-2.96 on SPARC, I'd say it's a "better safe than dealing with a duplicate bug that no one can hunt down later" thing.

2. I pulled out the glibc check after confirming that building with gcc-2.95 on a system with glibc 2.3 produces the same segfaulting binary.  It's all GCC's fault, glibc is an innocent bystander.

3. I changed __sparc64 (a define that doesn't always (or ever, in some systems) exist to __sparc__, since while I reported this happening on a sparc64 system, one must realise that sparc64 systems are sparc32 in user-space (well, most of them are).  Compiling for sparc32 or sparc64 targets produces the same bug, so a generic __sparc__ test seems to make more sense.

With this new and improved line, the Ugly Hack(tm) to work around this compiler issue seems to work just fine.  Thanks for the help hunting it down and giving it some TLC.

> Clearly, this is a compiler/glibc bug. Sounds like 
> something you guys at Debian might wanna fix as well. 

Certainly looks like a GCC bug, yes.  However, it's a GCC bug in our stable release (which doesn't get compiler updates, or PHP updates for that matter, with the exception of security fixes), so it's not going to get fixed (this problem doesn't show up in sarge (our upcoming stable release) or sid (unstable)).  Doesn't stop me from trying to run the latest PHP on production machines running Debian/stable, however. :)

I'm not sure how many other Debian/SPARC users try to use the latest PHP on stable systems, but I'm sure they'd thank you for your efforts.  Most probably use the php4 packages provided by Debian (and packaged by me, ironically) that work just fine, but there's always a few build-from-source types out there.

As an added note, I didn't bother trying to add a glibc or linux test in there, as most arch-specific compiler bugs seem to span OSs, and this bug would probably affect Solaris as well.  We don't have a Solaris machine in-house anymore for me to test this theory on, however.

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

This bug has returned in PHP 4.3.7 with the changes made in ext/standard/config.m4, rev 1.47.2.14.

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

I don't have a Sparc machine in front of me right now to test, but looking at CVS, I don't see HOW this can be fixed, as the relevant portions of config.m4 haven't been touched since I reopened the bug.

If you have fixes, provide a patch.

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".