Date:	Tue, 26 Aug 1997 19:31:35 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
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:	<Pine.SUN.3.91.970826192344.6359E-100000@is>
MIME-Version:	1.0

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.

- Raw text -