When I compile the latest dev-php5/pecl-apc it gets compiled with mmap as var as I can see. But the strange thing is my USE-flag is -mmap. What i see while compilation: checking whether we should use mmap... yes This leads to the idea that --enable-apc-mmap was passed to configure, but I'm not a gentoo-ebuild-developer so I'm not sure. Maybe it's a upstream bug. I found this bug, beacause my apache returned some errors, although I was sure mmap was turned off: "PHP Startup: apc.shm_segments setting ignored in MMAP mode in Unknown on line 0" Reproducible: Always Steps to Reproduce: 1. Compile pecl-apc with -mmap useflag and look at the configure script. Actual Results: ... checking whether we should use mmap... yes ... Expected Results: ... checking whether we should use mmap... no ...
Created attachment 257803 [details] emerge --info
Created attachment 257805 [details] emerge -v pecl-apc > build.log
(In reply to comment #0) > .. with mmap as var as I can see.... "as far as i can see" of course
The build.log seems incomplete - there should be one in /var/log/portage/.
Created attachment 257843 [details] real build.log (In reply to comment #4) > The build.log seems incomplete - there should be one in /var/log/portage/. > I finally found the way to generate a real build log.
OK, I think I know what the problem is. It should be easy to fix...here. The catch is that it's a mostly silent bug, that may affect many more packages. php-ext-source-r1.eclass is EAPI=0, php-ext-source-r1.eclass is EAPI=2. This ebuild was not properly adjusted to this fact. 'my_conf="--enable-apc" enable_extension_enable "apc-mmap" "mmap" 0' belongs to src_configure now. But, as I said, I wouldn't be surprised, if there were other packages affected by this change.
Good catch! Fix should be available in CVS.
I think the same applies to pecl-memcache-3.0.5-r1...although i do not have problems with it.
