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" Subject: Re: Fw: Patch for statfs.c Cc: Eli Zaretskii , Martin Str|mberg , ceo AT nbensacomputers DOT com In-Reply-To: References: <5 DOT 0 DOT 2 DOT 1 DOT 0 DOT 20010109194232 DOT 0274eec0 AT pop5 DOT banet DOT net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 At 09:45 AM 1/10/01 +0200, Eli Zaretskii wrote: >> 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)