Mail Archives: djgpp/1998/03/18/17:01:50
Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> 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 <COFF image>". 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-<yaddayadda> 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)
- Raw text -