pfile@sprite.berkeley.edu (Rob Pfile) (03/26/91)
I'm sorry if this is a FAQ topic, but I have not seen any discussion on it: I downloaded gcc-1.39-aux.tar.Z from afsg.apple.com, and proceeded to unpack it on to my macII (8MB ram, Quantum P210S, 8*24 GC, if that makes any difference). Installation of gdb went OK, but running the fixincludes script actually crashed very badly either when fixing sys/file.h or right after it. It reports that a substitute pattern match fails, dumps core, and appears to try to exit gracefully without updating the rest of the include files. Is there something I didnt do? The variable at the beginning of fixincludes was already correct, that is /usr/local/Gnu. I think something went wrong, because even though I later successfully compiled xtetris2.04, my little program to simply open disk slice 31 will not compile; gcc complains that O_RDONLY is undefined... This is probably pretty bad, since most programs probably use that #define... Do I need to include a different file under gcc? Thanks for any help. Rob Pfile pfile@sprite.berkeley.edu
coolidge@cs.uiuc.edu (John Coolidge) (03/27/91)
pfile@sprite.berkeley.edu (Rob Pfile) writes: > [...] running the fixincludes >script actually crashed very badly either when fixing sys/file.h or right >after it. It reports that a substitute pattern match fails, dumps core, >and appears to try to exit gracefully without updating the rest of the >include files. >Is there something I didnt do? The variable at the beginning of fixincludes >was already correct, that is /usr/local/Gnu. This is a known problem; I haven't had time to go sort it out yet. It seems that fixincludes is stressing one utility or another in the wrong way. I'll attempt to find it and put out a fix; I also need to test fixincludes with the 2.0.1 header files. >I think something went wrong, because even though I later successfully compiled >xtetris2.04, my little program to simply open disk slice 31 will not compile; >gcc complains that O_RDONLY is undefined... This is probably pretty bad, since >most programs probably use that #define... This could be the (moderately infamous) -D_BSD_SOURCE -D_SYSV_SOURCE problem. Apple's cc defines both of these symbols because the ^#@$ header files don't do what you expect them to do otherwise. I think this is brain damage, so I don't have gcc define them (in the hope that someone will get annoyed enough to fix things, perferably someone at Apple who can get the fix into the next release...). My opinion is that _AUX_SOURCE should turn on the A/UX superset of features and that BSD_SOURCE or SYSV_SOURCE should turn on whatever is not in default A/UX and turn off whatever is there that is incompatible with the given type. --John -------------------------------------------------------------------------- John L. Coolidge Internet:coolidge@cs.uiuc.edu UUCP:uiucdcs!coolidge Of course I don't speak for the U of I (or anyone else except myself) Copyright 1991 John L. Coolidge. Copying allowed if (and only if) attributed. You may redistribute this article if and only if your recipients may as well.