Newsgroups: comp.os.msdos.djgpp From: tob AT world DOT std DOT com Subject: Re: Thanks and report (Making gcc 2.8.1; help requested) Message-ID: Sender: tob AT world DOT std DOT com (Tom Breton) Reply-To: tob AT world DOT std DOT com Organization: BREnterprises References: Date: Wed, 18 Mar 1998 21:24:55 GMT Lines: 119 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk Eli Zaretskii writes: > On Wed, 18 Mar 1998 tob AT world DOT std DOT com wrote: > > > What happens is that bash, when running COFF image files, makes > > go32-v2 try to call go32 and also fail to find it. Really weird. DOS > > runs 'em fine, both the *.exe's and "go32-v2 ". Under DOS > > go32-v2 doesn't even try to find go32 (tested by renaming it: no > > change) > > This is some snafu specific to your system. I think so too. > go32-v2 should only try > to find go32.exe if the first opcode in the COFF image it finds is > what DJGPP v1.x was producing; otherwise it runs the COFF image by > itself. I cannot imagine how could it be in error. Could you please > set GO32_V2_DEBUG=y in the environment, run the original Makefile > (without the $(exeext) hack) again and tell what does go32-v2 print? Same as before: "go32/v1: cannot find v1's go32.exe" That error-message string is found in go32-v2.exe, of course. Here's what I used: [begin test.sh] GO32_V2_DEBUG=y ### # Fails, saying "go32/v1: cannot find v1's go32.exe" ./genattr ./config/i386/i386.md > tmp-attr.h ### # Fails exactly the same way: # ./genattr ### # Succeeds, apparently 100% normal. # ./genattr.exe ./config/i386/i386.md > tmp-attr.h ### # Comparison: a COFF image that has nothing to do with the gcc 2.8.0 # distribution. # # Fails exactly the same way: # /pro/allegro/ultra/a.out [end test.sh] I tried it in a half dozen ways, and it's the same thing, whether run from bash, from DOS "sh test.sh", or from bash interactively. I had set GO32_V2_DEBUG=y in DOS the whole time too. > > * I had to truncate the tmp- file names in the makefile so > > move-if-changed would admit the files existed. Right, I don't have > > long filenames. I know that. > > This might be a bug in the ported source distribution. Robert, can > you see if there's a problem here on non-LFN systems? If it's any help, here are all the lines that gave that problem: $(srcdir)/move-if-change tmp-config.h insn-config.h $(srcdir)/move-if-change tmp-flags.h insn-flags.h $(srcdir)/move-if-change tmp-codes.h insn-codes.h $(srcdir)/move-if-change tmp-recog.c insn-recog.c $(srcdir)/move-if-change tmp-opinit.c insn-opinit.c $(srcdir)/move-if-change tmp-extract.c insn-extract.c $(srcdir)/move-if-change tmp-attrtab.c insn-attrtab.c $(srcdir)/move-if-change tmp-output.c insn-output.c $(srcdir)/move-if-change tmp-bc-arity.h bc-arity.h $(srcdir)/move-if-change tmp-bcopcd.h bc-opcode.h $(srcdir)/move-if-change tmp-bcopnm.h bc-opname.h Truncating the tmp-* filenames to 8 letters + extension fixed it and caused no other problems I could see. > > * For reference by anyone who tries this in the future, you really do > > need the latest make, make-3.761. make-3.73 won't do it. > > Make 3.73 didn't support Unix-like shells. You need 3.75 or later. > Doesn't README.dos say so? Yes, in hindsight I would have immediately fetched the latest GNU make instead of first trying the GNU make I already had installed. But it wouldn't hurt to mention that despite temptation, the reader *can't* assume it's possible to substitute an earlier make (than mak375.zip, but I can only vouch for mak3761b.zip) It might be good to mention that seeing an error like... c:\usr\tmp\dj000000.bat[1] Unknown command "." ...means that the GNU make being used isn't recent enuf, and he should get mak3761b.zip or later. The file is README.djgpp, and it says: Robert writes in readme.djgpp: > Because it is really not possible for me to check for any needed program > I include here only a list of packages which you will need at least: > > - fil316b.zip > - find41b.zip > - grep20b.zip > - mak3761b.zip > - sed118b.zip > - shl112b.zip > - txt119b.zip Tom -- When you see a spam, just remember that a spammer is some fool who just can't believe that if they bother a million people, they'll get fewer than a dozen interested responses. (Copy this so more wannabe spammers see it)