Message-Id:	<5.0.2.1.0.20010110233939.0275e8a0@pop5.banet.net>
X-Sender:	usbanet DOT farley3 AT pop5 DOT banet DOT net
X-Mailer:	QUALCOMM Windows Eudora Version 5.0.2
Date:	Thu, 11 Jan 2001 00:01:09 -0500
To:	djgpp-workers AT delorie DOT com
From:	"Peter J. Farley III" <pjfarley AT banet DOT net>
Subject:	Re: Fw: Patch for statfs.c
Cc:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, Martin Str|mberg <ams AT ludd DOT luth DOT se>,
	ceo AT nbensacomputers DOT com
In-Reply-To:	<Pine.SUN.3.91.1010110094513.2164E-100000@is>
References:	<5 DOT 0 DOT 2 DOT 1 DOT 0 DOT 20010109194232 DOT 0274eec0 AT pop5 DOT banet DOT net>
Mime-Version:	1.0
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

At 09:45 AM 1/10/01 +0200, Eli Zaretskii wrote:
<Snipped>
 >> Agreed, that seems to be the only way.  The problem is, I can't get 

 >any
 >> of the versions I've tried so far to give the results that df from
 >> fil316b.zip gives.  I will try building fil316s.zip with the stock
 >> v2.03 libc.a and see what results I get from that.
 >
 >Yes, this seems like a good idea.

No luck.  I'm reasonably sure I did this in a pretty vanilla v2.03 
setup, although with Mark E.'s most recent beta of bash in there.  The 
libc and include headers were definitely stock versions.  I get the 
same incorrect (well, different from fil316b.zip) results after 
rebuilding with v2.03 code.

I'm stumped.  Someone who knows Intel object code and DJGPP internals 
could run gdb or some other object code debugger against the 
fil316b.zip version, which seems to have had all of the symbols 
stripped out of it, though the make doesn't do that when it 
builds.  Maybe the install process does the strip, I didn't run the 
make install to check.  I don't feel qualified to perform such a 
debugging.

If we could agree on using a single CDROM that at least two people 
have, I would suggest asking all who have it to try each of these 
versions of df on that same CDROM:

1.	Stock df from fil316b.zip
2.	df from rebuilding fil316s.zip with stock libc v2.03
3.	df from rebuilding fil316s.zip with CVS libc
4.	df from rebuilding fil316s.zip with CVS libc after rebuilding libc 
with Martin's latest version of statfs.c

If only (1) returns a different value for the same CDROM on multiple 
systems, then I think we have to assume that some unknown version of 
statfs resides in the df binary in fil316b.zip.  Can anyone else think 
of a different interpretation or a better test?

Anyone have any ideas about a CDROM which more than one person is 
likely to have?  I list below some CDROM's I know I have, to start off 
the search:

A.	PowerQuest Partition Magic installation CDROM, versions 2.0, 3.0, 
4.0, and 5.0.
B.	Corel Linux CDROM's, versions 1.0, 1.1, 1.2
C.	RedHat Linux CDROM's, version 6.0
D.	Adaptec EZSCSI CDROM, version 4.0
E.	Quicken Deluxe, version 6.0
F.	Quickbooks Pro versions 6.0 and 2001
G.	WordPerfect Suite version 8.0 Professional and 2000 Professional
H.	ProComm Plus, version 3.0
I.	Watcom C/C++ version 10.5

I have others, but I hope that's enough of a list to start with.

---------------------------------------------------------
Peter J. Farley III (pjfarley AT dorsai DOT org OR
                      pjfarley AT banet DOT net)

- Raw text -