Bug 186669 - eA doesn't support php 5.1
eA doesn't support php 5.1
Product: Fedora
Classification: Fedora
Component: php-eaccelerator (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Matthias Saou
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2006-03-25 02:40 EST by Bart Vanbrabant
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-05-23 06:46:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Bart Vanbrabant 2006-03-25 02:40:22 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.
Comment 1 Matthias Saou 2006-04-07 09:38:08 EDT
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?
Comment 2 Bart Vanbrabant 2006-04-09 07:02:45 EDT
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.
Comment 3 Bart Vanbrabant 2006-04-11 09:59:13 EDT
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
nasty errors.

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.
Comment 4 Matthias Saou 2006-04-11 10:18:38 EDT
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.
Comment 5 Bart Vanbrabant 2006-04-11 10:27:33 EDT
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
Comment 6 Bart Vanbrabant 2006-04-11 10:55:04 EDT
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.
Comment 7 Bart Vanbrabant 2006-04-11 11:20:19 EDT
I've updated the spec file again. I've added patch from the other dev that
silences some other warnings generated on x86_64.
Comment 8 Matthias Saou 2006-04-11 12:06:37 EDT
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?
Comment 9 Bart Vanbrabant 2006-04-11 12:38:14 EDT
That's perfectly normal, the eA spinlock implementation is in assembly. That's
why it can only be compiled on x86
Comment 10 Matthias Saou 2006-04-11 12:55:10 EDT
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 :
Comment 11 Matthias Saou 2006-05-23 06:46:46 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.