Today I was able too complete the build. 
I had to add some Lines in configure and ZendAccelerator.h. (corresponding to <sys/fcntl.h>)
> # elif defined(__SVR4)
> #   define FLOCK_STRUCTURE(name, type, whence, start, len) \
>          struct flock name = {type, whence, start, len, 0, 0, 0 }

Also it was necessary to translate some files of ext/opcache/ with dos2unix. Maybe the problem has been long lines concatunated whith "\CRNL" instead of "\NL"

Still it's a hack, not a tested solution. ;-)

FAILED TEST SUMMARY
...
Test flock() function: Basic functionality [ext/standard/tests/file/flock_basic.phpt]
Test flock() function: Variations [ext/standard/tests/file/flock_variation.phpt]
...

Last info before resigning. :-( Configure can't link to flock()
> configure:19164: checking for flock
> "conftest.c", line 161: warning: statement not reached
> Undefined symbol     first referenced in file
> flock                conftest.o

Maybe someone smarter than me, may use the informations on http://www.perkin.org.uk/posts/solaris-portability-flock.html

reh's solution seems to work for me.
After converting the \r\n's to \n and fixing the three spots (configure, 
ext/opcache/ZendAccelerator.h, and ext/opcache/config.m4) where the flock test 
is done, I was able to configure and build successfully.  I haven't seen any 
issues so far.

using Solaris Studio 12.3 on:

# cc -V
cc: Sun C 5.12 SunOS_i386 2011/11/16
# uname -a
SunOS Heimdall 5.10 Generic_147148-26 i86pc i386 i86pc

PHP Version:5.5.0 and 5.5.1
OS:CentOS release 6.4 (Final)
Kernel: 2.6.32-358.6.2.el6.i686

Error:
checking for mmap() using shm_open() shared memory support... no
checking for mmap() using regular file shared memory support... no
checking for known struct flock definition... configure: error: Don't know how to define struct flock on this system, set --enable-opcache=no
make: *** No targets specified and no makefile found.  Stop.
make: *** No rule to make target `install'.  Stop.

> checking for known struct flock definition... configure: error: Don't know how 
to define struct flock on this system, 

I don't have this problem with my Scientific Linux 6.4.

I tested many times. Influence and Linux OS version.
CentOS 5 32/64bit and CentOS 6 64bit has been passed, but CentOS 6 32bit ./configure error: 
checking for known struct flock definition... configure: error: Don't know how to define struct flock on this system, set --enable-opcache=no

For me it looks like two probs.
1. Lineterminators
2. Flock library

Both seems to be tested only with GCC (1) and GLIBC (2) which is likely standard on most linux systems. It is just a question of the portability of the code.

Guys, since you already got it working, how about providing a patch?

Sorry, but I can't provide a patch. 
My solution from the first post is roughly a workaround, to get the code compiled. But 'make test' still fails.
My skills as c-programmer are too poor, to understand the system librarys in detail. :-(

I had the same problem trying to compile in CentOS 6.4.

I needed to install libtool-ltdl-devel and then the problem went away.

Bug seems to be gone in PHP 5.5.9. Compiling with '--enable-opcache' works fine, loading the module in php.ini + opcache.enable=1 works as well. phpinfo() confirms that opcache is up and running.

Tested with Solaris 11.1 x86/amd64 + Solaris Studio 12.3

I've tried on PHP-5.5.10 and -5.5.9 with libmcrypt-2.5.8 with no success. I have confirmed that removing "--with-mcrypt..." allows configure to complete successfully. It should be noted that I am doing this on Heroku.

My libmcrypt configure directives:

./configure --prefix=/app/vendor/mcrypt \
            --disable-posix-threads \
            --enable-dynamic-loading

My PHP configure directives:

./configure --prefix=/app/vendor/php \
            --with-mysqli \
            --with-gd \
            --with-curl=/usr/lib \
            --with-config-file-path=/app/vendor/php \
            --with-openssl \
            --enable-fpm \
            --with-zlib \
            --enable-mbstring \
            --disable-debug \
            --disable-rpath \
            --enable-gd-native-ttf \
            --enable-inline-optimization \
            --with-bz2 \
            --with-mhash \
            --enable-zip \
            --with-gettext \
            --with-jpeg-dir=/usr \
            --with-png-dir=/usr \
            --enable-exif \
            --enable-bcmath \
            --enable-calendar \
            --enable-sockets \
            --with-xmlrpc \
            --with-mcrypt=/app/vendor/mcrypt \
            --without-pdo-sqlite \
            --without-sqlite3

Per changelog (http://www.php.net/ChangeLog-5.php#5.5.0), the Zend Opcache extension was enabled by default since 5.5.0. Otherwise, the extension was available for install from PECL. Not sure what happens behind the scenes in a default compilation of version 5.5.x vs compiling a lesser version and installing the extension via PECL, but something doesn't seem to be working correctly in 5.5.x.

Personally, my main concern was that I'd hit some impasse, and that disabling the opcache extension would be a "game ender." As it is, the extension wasn't enabled by default as recent as the 5.4.x branch, so I think I can argue that disabling it is acceptable for the time being. I'm also using mecachier and nginx, and won't be serving too much to begin with, so I'm fine with disabling it.

I am interested to see what comes of this bug. Any extension to help speed up the response time of our apps is a good idea to me.

Could be be similar to https://bugs.php.net/bug.php?id=65423 ? Try installing libtdl-dev, or otherwise the complete GNU Libtool installation that includes libtdl. 

Libtdl is required for Opscache compilation. 


Hope that helps.

Are there still issue compiling OPcache with any of the actively
supported PHP versions[1]?

[1] <https://www.php.net/supported-versions.php>

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.