X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs Date: Mon, 2 Aug 1999 18:57:53 +0200 (MET DST) From: Hans-Bernhard Broeker X-Sender: broeker AT acp3bf To: djgpp-workers AT delorie DOT com Subject: Re: Changes in Binutils 2.9.1 In-Reply-To: <199908021431.KAA01036@envy.delorie.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Mon, 2 Aug 1999, DJ Delorie wrote: > > Does anybody see any problems with this? How about cross-building: > > can we rely on `stubify' and `od' to be available then? > It would be best if it was autoconf detected. If od and stubify were > available, it should enable extra makefile steps to regenerate the > stub pattern. Or, for similar purposes, why not install the 'stub.h' generated as part of the DJLSR build process, into $(DJDIR)/include/sys/go32stub.h or similar? Once that's done (and DJGPP 2.03 or later released), binutils could be changed to always for "sys/go32stub.h", and use the copy coming with the binutils source only if none was found. The latter should only happen if someone's building with an older djcrx*.zip. For the short term, it might be seen as part of the duty of whoever makes binutils binary distribution packages for DJGPP to ensure that the latest stub.h is included, and used. FSF patches for this part of binutils should probably be submitted by DJ himself, every time a new DJGPP release is made. Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.