![[APACHE DOCUMENTATION]](../images/sub.gif) 
 See Also: Compatibility notes
cd to your apache_1.2.1 directory, and
	type patch -s -p1 < /path/to/patchfile.  Then rebuild
	Apache.
-DNO_SLACK to
	EXTRA_CFLAGS in
	your Configuration file, re-run Configure
	and rebuild your server.  This disables the
	descriptor slack workaround
NO_SLACK or patch provided by the previous bug are applied.)
    Solaris 2.5.1 (and probably other versions of Solaris) appear to have
    a race condition completely unrelated to all the others.  It is possible
    during a SIGHUP that the server will fail to start because it will not
    be able to re-open its sockets.  To our knowledge this has only shown
    up during testing when we pummel the server with as many SIGHUP requests
    per second as we can.  This appears unrelated to the similar sounding bug
    described in PR#832.
    
-DUSE_FLOCK_SERIALIZED_ACCEPT to the
    EXTRA_CFLAGS line in your Configuration and rebuild.
    (If you encounter problems with that, you can also try
    -DUSE_FCNTL_SERIALIZED_ACCEPT.)
    This affects any architecture that doesn't use one of the
    USE_xxxxx_SERIALIZED_ACCEPT definitions, see the
    source file conf.h for your architecture.
    This will be tracked as
    PR#467.
    %2f. This will be tracked as
    PR#543.
    SunOS4 has a kernel bug in the allocation of memory for the mbuf table. When it fills up, the result is a Panic the next time any routine tries to set something in an imaginary mbuf beyond the range of the table. Due to buggy browser behavior and the lack of a FIN_WAIT_2 timeout on SunOS4, "KeepAlive Off" is necessary to avoid filling up the mbuf table on busy sites.
gcc: noinline: No such file or directory". Fix
    is given in PR#695.
    -lbind
    to EXTRA_LDFLAGS in Configuration. See
    PR#616
    and the
    Apache FAQ.
    created shared memory segment #730499"
    in error_log is not an error and should be ignored. See
    PR#696.
    "mod_include.c", line 1123: warning: end-of-loop code not
    reached. This is a bogus warning and can be ignored.
    See PR#681.
     
