From: "Laurynas Biveinis" <lauras AT softhome DOT net>
Date: Thu, 28 Jun 2001 18:21:48 +0200
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Cc: Tim Van Holder <tim DOT van DOT holder AT pandora DOT be>, djgpp-workers AT delorie DOT com
Subject: Re: Build failure of CVS docs
Message-ID: <20010628182148.A390@lauras.lt>
Mail-Followup-To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>,
	Tim Van Holder <tim DOT van DOT holder AT pandora DOT be>,
	djgpp-workers AT delorie DOT com
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1010628131135 DOT 12284D-100000 AT is>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.SUN.3.91.1010628131135.12284D-100000@is>
User-Agent: Mutt/1.3.18i
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


> Unless the library build procedure is run on a Unix box in cross-build
> environment, these extra CR characters shouldn't matter, since
> makeinfo reads input in text mode, and our libc removes _all_ CR
> characters, not just those before an LF.
> 
> That is why I didn't see the problem on my machine, although my CVS
> client also adds CR to each LF.

Then how comes I encountered this problem, and fixing line endings
made it go away, everything else being equal?

Laurynas