Date: Tue, 1 May 2001 12:00:24 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: "Mark E." <snowball3 AT bigfoot DOT com>
cc: djgpp-workers AT delorie DOT com
Subject: Re: ANNOUNCE: Fileutils 4.0 beta 2
In-Reply-To: <3AEDBEAE.25112.256BC@localhost>
Message-ID: <Pine.SUN.3.91.1010501120002.29799I-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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


On Mon, 30 Apr 2001, Mark E. wrote:

> > If the alternative stubs aren't that large, we could increase the
> > fixed space allocated for the stub in bfd.
> 
> I checked and the stubs are ~14K so this won't work.

Perhaps having separate targets is the simplest way out of this.
After all, if the target is detected automatically, this should be
almost invisible to the user.

Btw, just to make sure I understand the issue correctly: is it true
that the size of the stub is hard-wired into the BFD targets used by
DJGPP?  I mean, there's the GO32STUB environment variable which can
change the stub they use, so the contents of the stub can clearly be
controlled without changing any code.  So is it just the size which is
fixed?