~x86, gcc is 3.3.2-r2, glibc is 2.3.2-r8, kernel is clone of linus' bk repo. Upgrading from apache 2.0.47. Apache sees that sctp is available, but the compile dies with: sockopt.c: In function `apr_socket_opt_set': sockopt.c:257: error: `SCTP_NODELAY' undeclared (first use in this function) sockopt.c:257: error: (Each undeclared identifier is reported only once sockopt.c:257: error: for each function it appears in.) make[4]: *** [sockopt.lo] Error 1 make[4]: Leaving directory `/home/portage/portage/apache-2.0.48/work/httpd-2.0.48/srclib/apr/network_io/unix' SCTP_NODELAY is defined in /usr/src/linux/include/net/sctp/user.h which is included by /usr/src/linux/include/net/sctp/constants.h, which is included by /usr/src/linux/include/net/sctp/sctp.h, among others. I tried putting the /usr/src/linux/include/net/ tree at /usr/include/net and symlinking sctp.h into /usr/include/netinet, based on what apr looks for, but that did not succeed. A test of manually running gcc (same args as libtool as invoked by make, but with -save-temps instead of -pipe) shows (in sockopt.i) that sctp.h is not included, hense the failure of my attempt to fix.... Any ideas?
After more research I figured out a solution. Something in the current glibc or kernel triggers apache's sctp support, but the usermode lib and includes are not installed anywhere. Solution is to grab the latest release from lksctp.sf.net (a simple econf;emake;einstall ebuild is all it needs) and install that. Then apache compiles happily, presumably with sctp support.
2.0.48 too ?
uhh i wouldnt mess around with /usr/include/{net,netinet} ... those are santized glibc provider header files which are meant to be the interface between userspace and the kernel ... ive seen similar problems with signal.h ... that is, glibc defines the macro __attribute_used__ as does the linux-2.6 header files ... but the 2.6 header files dont check to see if __attribute_used__ is already defined so it causes gcc to print warnings which sometimes causes configure tests to fail ... if you wish to mess around with 2.6.x header files, then *only* do so with linux/ and asm/, NEVER touch any other directory ... if you do, the broken pieces are yours to put together ;) for now, remove your 2.6.x header files from /usr/include and use the 2.4.x header files ... if apache emerges just fine, then replace your linux/ and asm/ directories with links to the 2.6.x header files ... if apache then fails, edit the linux/compilter-gcc*.h files and put #ifdef macro's around the __attribute_used__ definition and see if apache works ... if the answer is 'yep, apache works fine', then from the gentoo stand point the answer is 'if you use 2.6.x header files then it's your problem to fix bugs' :)
re changing /usr/include: I did undo the manual changes I made; those were just for testing. I'll be leaving the rest of it as the glibc et al ebuilds put it. As for the SCTP_NODELAY bug, the problem is that apr sees sctp support even though lksctp is not installed. Installing lksctp is the fix. I installed mirror://sourceforge/lksctp/lksctp-tools-2.6.0-test7-0.7.4.tgz and apache compiled fine. (I didn't do an ebuild for it, but it is a simple econf;emake;einstall ebuild; nothing special is required.)
Please fix the basic Gentoo system so Apache2 will compile and install. It doesn't work on 2.4-gentoo compiled system nor does it compile with kernel 2.6 headers (for other reasons)
the core problem boils down to the fact that your kernel headers in /usr/include{asm,linux} don't match the version for your kernel. This is _very_ important in general. If you are running a 2.6 kernel, then 2.6 headers should be there, and glibc should be compiled for a 2.6 kernel. I've put in a workaround for the moment that tells apache2 that SCTP is _not_ present, but this will need to be revisited when we start support SCTP (with the 2.6 release).
Has anybody built a sanitised set of linux-2.6 headers for /usr/include yet? Copying the files from the /usr/src/linux-xxx results in a mess since a lot of things won't compile and trying to get any help from linux-kernel results in you getting your head ripped off since it's "not their job" to sanitize the headers for userspace. p.s. copying 2.6 headers to /usr/include doesn't work.
no one has made sanitized 2.6 headers and i dont know about your claim that 2.6 headers breaks 'a mess of things' ... it seems that the only real breakage atm is fbconsole ... maybe a few cd related stuff (usually only with kde though) ...
How best to explain.. replace your /usr/includes with 2.6.0 headers, try recompiling your machine. base stuff usually works. most multimedia stuff has problems, from small to large. it's getting better as some packages are fixed (think modversions.h vs. modsetver.h change) and _some_ kernel developers are sensible and write their headers sensibly. getting back to the subject on hand, what fix is in to fool apache2? it still fails on SCTP_NODELAY with the latest of gentoo-sources or 2.6 and fresh syncs.
# grep sctp /var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/config.cache ac_cv_header_netinet_sctp_h=${ac_cv_header_netinet_sctp_h=no} ac_cv_header_netinet_sctp_uio_h=${ac_cv_header_netinet_sctp_uio_h=no} ac_cv_sctp=${ac_cv_sctp=yes} notice the last line. apache still thinks sctp is available.
# emerge apache <configure process running> ... checking if SCTP protocol is supported... yes ... compile fails
to be honest, i dont think any work is/will be done about this ... perhaps if you do a lot of the legwork ? ;) i havent had any problems emerging apache-2.x while using 2.6.x header files ... but then again, perhaps my installation isnt trying to enable the same options as yours ...
my machines: checking if SCTP protocol is supported... no and compile works ;)
Created attachment 21643 [details, diff] pre-caches failed sctp support A better fix that actually works ;) Use: echo 'ac_cv_sctp=${ac_cv_sctp=no}' >> ${S}/config.cache
Just an explanation of things for the record. In short, the includes were found fine so configure attempted to compile a test program. Test program worked fine. Problem is that the SCTP_NODELAY isn't used in the test program so it didn't fail. That's defined elsewhere in the headers, not in the headers used in the test program. Thus precaching the global sctp setting instead of the headers setting was more effective. The configure test procedure tried to be intelligent about things..just didn't have enough data in the test.
ok blu3, i've added your other fix there.
