From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
To: <djgpp-workers AT delorie DOT com>
Subject: RE: ANNOUNCE: Fileutils 4.0 beta 2
Date: Fri, 27 Apr 2001 18:03:15 +0200
Message-ID: <CAEGKOHJKAAFPKOCLHDIAENKCCAA.tim.van.holder@pandora.be>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-reply-to: <9003-Fri27Apr2001094924+0300-eliz@is.elta.co.il>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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

> There are two ways:
>
>   - set FNCASE=y before zip'ping the package.
>
>   - edit the *.mft files so that they have the right letter-case, then
>     invoke zip with the manifest file as a response file, like this:
>
> 	   zip -9 fil40b.zip @manifest/fil40b.mft
Hmm - I think recent versions of zip already store the exact case on LFN
systems (I know my zip (2.3.3) has been doing so for a while (I last built
my own end of '99)).

> > >     - The problem with "ginstall -s" being unable to work with
> > >       PMODE/DJ-stubbed executables sounds disturbing.  Does ginstall
> > >       work with CWSDSTUB?  What about programs compressed with UPX?
> > >       If these don't work either, I think we need to fix `strip' to be
> > >       able to work with such programs.
> >
> > I don't know - I'll look into that.
>
> If the only problem is with `strip', then Mark probably should take a
> look at this.  The case of UPX is not very important (since
> compressing strips the program anyway), but CWSDSTUB and PMODE/DJ
> should IMHO be supported.
>
> In any case, "install -s" should not fail if `strip' didn't work,
> perhaps just print a warning message.

This is a bfd problem; it still uses a fixed-size stub area, so stubs that
aren't exactly as long as the standard stub used by bfd won't work. IIRC
this would be hard to fix, as most bfd routines expect to find the header
info (the coff header, for DJGPP executables) at the start of an object.
With a fixed-size stub, you could just have the stub as the first field
of the header (which is what I think is done now). But with a variable-sized
stub, this becomes much harder (and I don't know if bfd has the needed hooks
for it at the moment).