Red Hat Bugzilla – Bug 186669
eA doesn't support php 5.1
Last modified: 2007-11-30 17:11:28 EST
Description of problem:
eAccelerator doesn't work with php 5.1, we are working on this and the current
snapshots are pretty stable so eA 0.9.5 with php 5.1 support will be there soon.
I really don't see how 0.9.3 is able to build against php 5.1, this is
impossible and still it's in FE.
Simply because it's a snapshot. If you look at the %changelog you'll see it. I
should have also mangled the release tag to make it more evident, I guess.
Any idea when a final release that supports php 5.1 will be made?
In the next days we will be releasing a second beta. It really wouldn't hurt
using that one for FC5. We really feel this one is already more stable then eA
ever was. Some really big websites with +50 heads in a webcluster are already
using the development snapshots with php 5.1. But some obscure problems remain
and we want to try to sort them out to.
If you do use this one call the package 0.9.5-dev or 0.9.5-beta2, because that's
the way we refer to them in our bugtracker and website.
I'll post something here when beta2 is out.
We released eAccelerator 0.9.5-beta2. I updated the rpm package:
I've added a %post entry in the spec file to remove all cached scripts. This is
needed because between version the format can change. This will result in pretty
I've also included a patch to fix all compile error because of the more strict
compile options that fedora uses. I'll commit this patch later today but it
isn't in beta2.
Hmmm, that %post removal of the cache/php-eaccelerator/ directory will break
things, as it will be gone for good and not created again. I'm not sure what th
e best solution would be since removing cache/php-eaccelerator/* won't work
either when the argument list gets too long (and it is often the case on busy
Maybe with a "find" execution to remove all files older than "now" (thus
removing all previously created files, but not the ones being created since the
update? This would mean one "rm" execution/fork per file, which is definitely
much slower then a recursive rm of the entire directory.
rm -Rf /var/cache/eaccelerator will remove the directory
/var/cache/eaccelerator/ removes the contents of that directory.
But if that doesn't work the best way to do is:
find /var/cache/eaccelerator | xargs rm -Rf
xargs will make sure that the list isn't longer then the maximum length for the
I see the problem now. Removing these cached files is only usefull when the
webserver is stopped. So maybe better to leave it out, we are planning to add a
version to a cache file. This should solve this problem.
I've updated the spec file again. I've added patch from the other dev that
silences some other warnings generated on x86_64.
Alright, I'll check it out now. BTW, do you know if it was normal for spinlock
to not be detected on ppc in the svn200603090012 snapshot?
That's perfectly normal, the eA spinlock implementation is in assembly. That's
why it can only be compiled on x86
OK, then the extra configure option that is present in my latest package is
still required (it's not for FC-4... hmmm), since otherwise you get this :
I've now rebuilt 0.9.5beta2 (+ patches) for FC5 at last. It's been in devel for
a while and has been working fine for me.