Date: Tue, 26 Aug 1997 19:31:35 +0300 (IDT) From: Eli Zaretskii To: Vik Heyndrickx cc: djgpp AT delorie DOT com Subject: Re: rebuilding gcc - fix-header.exe fails on DOS systems. In-Reply-To: <34029E4F.4E82@rug.ac.be> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Tue, 26 Aug 1997, Vik Heyndrickx wrote: > I tried to recompile the development version of pgcc 2.7.2 (some recent > version) and I ran into the following problem: > There exists a fix-header program which checks the standard header files > for their ANSI and POSIX complianceness and modifies them (while copying > them into an include/ directory). I noticed that some crap is inserted > into this header files which is more than likely caused by the CR+LF > translation. Why does that program runs at all when you build GCC for DJGPP? Our headers are ANSI-compliant to begin with, so it shouldn't be run at all. That program (which was previously a shell script) is only needed when you install gcc over an existing non-ANSI library. The configuration script should make it so that it doesn't run, if you ask me. > So I ran dtou on everty header file, but this does not > solve the problem. Then I put _fmode = O_BINARY; at the beginning of the > main function. This solves it, but I cannot really pinpoint what exactly > is causing the trouble nor find a more elegant solution. Look for calls to fseek whose argument didn't come from an ftell call, but from byte counts in a memory buffer where a file has been read. Another possible source of such trouble is that they call stat and then use the st_size member of struct stat as the size of the file (then you have garbage at the end), instead of using whatever was returned by `read' or `fread'. And what's so inelegant about setting _fmode, anyway? IMHO, this is more elegant than to patch every call to `open' with O_BINARY. FWIW, Emacs uses the _fmode trick.