Re: FreeBSD 4.2 breakage (?)
Jeff Trawick [EMAIL PROTECTED] writes: Regarding _POSIX_SOURCE: Trivia on _POSIX_SOURCE from Tru64... /* * If user defines _POSIX_SOURCE and if _POSIX_C_SOURCE is not defined, * define _POSIX_C_SOURCE to be 1. (_POSIX_SOURCE maps to the POSIX 1003.1 * standard from 1990). */ This stuff can be really aggravating... I'm trying to figure out how to enable the declaration of _SC_CLK_TCK so that mod_status compiles on Tru64. YOY can't they have something like _ALL_SOURCE (like on OS/390) which says I want access to whatever you've got, standards be damned? -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: FreeBSD 4.2 breakage (?)
[ bringing this conversation just to [EMAIL PROTECTED] at this point ] On Mon, Feb 05, 2001 at 06:09:45PM -0500, Greg Hudson wrote: I spent a good amount of time trying to figure out the right combination to allow us to include string.h and strings.h (which is done by apr_want.h) without some redundant declaration warnings. Can we change apr_want.h not to include strings.h if APR_HAVE_STRING_H is defined? Not at this time. There are users of strcasecmp(), so the explicit inclusion of strings.h is needed to pick that up. [ it was the duplicate declaration of strcasecmp and friends which led me down this road. ] I don't know what the POSIX equivalent of strcasecmp is, but am quite willing to update code to switch over to it. Removing redundant-decl was the easy fix, but I didn't think it was the right fix. Removing POSIX_SOURCE is also the easy fix, but I don't think the right fix :-) Well, it is certainly wrong to define _POSIX_SOURCE and then include strings.h, even if it doesn't happen to break anything at the moment like sys/socket.h does. I notice that apr_file_io.h also drags in sys/uio.h, also a non-POSIX header. Once again, _POSIX_SOURCE is not compatible with this behavior. Fine. Then we clean out the sys/socket include and the sys/uio include. I'll do so this evening. I don't have a ready solution for strings.h, however. Because we *do* use strcasecmp, I don't know a better way to pick it up. I don't want to rely on /not/ including strings.h if string.h is present. Who knows if string.h will define strcasecmp? GNU's happens to do so, but what about elsewhere? From that point, I said gotta include both. now how do I prevent the extra definition of strcasecmp? Even if we ultimately back out the POSIX_SOURCE thing, cleaning out the BSDisms from internal and public APR will assist with portability. [ I'm presuming that POSIX is more portable than BSDisms ] Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: FreeBSD 4.2 breakage (?)
It might be the Makefile because i can compile it manually. $ gcc -g -Wall -c svn_string.c -I../../apr/include -I../../subversion/include $ ls -l svn_string.o -rw-r--r-- 1 root wheel 19336 Feb 5 11:47 svn_string.o --pete Ben Collins-Sussman wrote: Boy, I'm bit out of my league here when it comes to portability macros. I got a huge cvs update of both subversion and apr this morning, and while apr builds cleanly, the very first subversion file I try to compile (svn_string.c) that includes apr.h gives me this error: - In file included from ../../apr/include/apr.h:96, from ../../apr/include/apr_lib.h:58, from svn_string.c:18: /usr/include/sys/socket.h:47: syntax error before `sa_family_t' /usr/include/sys/socket.h:47: warning: data definition has no type or storage class /usr/include/sys/socket.h:155: syntax error before `u_char' /usr/include/sys/socket.h:166: syntax error before `u_short' /usr/include/sys/socket.h:180: syntax error before `u_char' /usr/include/sys/socket.h:182: `u_char' undeclared here (not in a function) /usr/include/sys/socket.h:184: `u_char' undeclared here (not in a function) /usr/include/sys/socket.h:184: `u_char' undeclared here (not in a function) /usr/include/sys/socket.h:387: syntax error before `u_short' gmake[3]: *** [svn_string.lo] Error 1 - The problem is that apparently u_char isn't defined before including sys/socket.h (??) I went so far as to irrationally remove my apr/ subdir and checkout a fresh copy; still no dice. I need a clue here.
Re: FreeBSD 4.2 breakage (?)
/usr/include/sys/socket.h:47: syntax error before `sa_family_t' [etc.] The problem is the -D_POSIX_SOURCE which Greg Stein added last night. I was thinking of sending mail about it at the time, but decided he had probably done all the necessary footwork; I guess he missed something. If you define _POSIX_SOURCE, you cannot portably include system headers which are not specified by POSIX (including them indirectly through apr header files doesn't change anything). A well-behaved system will work anyway, but many systems will fail confusingly like you reported; sys/types.h doesn't define something like u_char which is used in the non-POSIX header file. Remove the -D_POSIX_SOURCE and things should build again, or at least shouldn't run into this problem.
Re: FreeBSD 4.2 breakage (?)
I spent a good amount of time trying to figure out the right combination to allow us to include string.h and strings.h (which is done by apr_want.h) without some redundant declaration warnings. Can we change apr_want.h not to include strings.h if APR_HAVE_STRING_H is defined? Removing redundant-decl was the easy fix, but I didn't think it was the right fix. Removing POSIX_SOURCE is also the easy fix, but I don't think the right fix :-) Well, it is certainly wrong to define _POSIX_SOURCE and then include strings.h, even if it doesn't happen to break anything at the moment like sys/socket.h does. I notice that apr_file_io.h also drags in sys/uio.h, also a non-POSIX header. Once again, _POSIX_SOURCE is not compatible with this behavior.
Re: FreeBSD 4.2 breakage (?)
Regarding _POSIX_SOURCE: What did this solve again? Perhaps my knowledge needs updating, but it wasn't long ago that there was no ratified POSIX standard which covered the networking APIs. I am pretty sure that no POSIX standard covers everything which Apache/APR needs. Frankly, I'm not too concerned that Apache or APR might use some interface which is in no POSIX standard. What is important is that Apache/APR build and run on as many platforms as practical. Whether the standard in vogue is POSIX (which one?), Single UNIX, or whatever, some systems wouldn't implement the new stuff at all and others wouldn't implement it correctly. The same thing is true for the different levels of the much more interesting* single Unix specification. Heck, some systems we work on haven't had new releases in ages. We just have to wander through the many flavors of God's own OS the best we can. *much more interesting because Unix95 (and later) actually specify an interesting enough set of interfaces that you can expect to write a real program using those interfaces; POSIX was never a rich enough set; did anybody hear of Microsoft's original POSIX box on NT? it was POSIX compliant at the programming interface level but you couldn't do anything useful with it -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
