Message-ID: <810E4FF60FEBD41196C60008C786C6D928DFC1@mwymail1.midwaygames.internal> From: "Thompson, Dan" To: "'djgpp AT delorie DOT com'" Subject: Problem running make in WIN2K CMD Date: Fri, 16 Mar 2001 15:03:12 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0AE5C.83230AF0" Reply-To: djgpp AT delorie DOT com This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C0AE5C.83230AF0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AE5C.83230AF0" ------_=_NextPart_001_01C0AE5C.83230AF0 Content-Type: text/plain; charset="iso-8859-1" HELP! I have been writing makefiles to run under djgpp; GNU-make, including the djgpp iteration, blows away NMAKE (no big news flash here). I know that it may be a problem running djgpp under command-line CMD.EXE in Windows 2000, but that is the environment the MS-heads here have selected. I have been having quite a series of problems and inconsistencies, e.g. moving from make 3.73 to 3.79.1, but have resolved most of them. I have just slammed into a wall, though. The project that is being configured to build with GNU-make is a decent-size directory tree. The build-tree has been set up to fully recurse from any location in the tree. Herein lies one of the major inconsistencies: when doing a build from the root of the tree (or any sufficiently large branch), the results are unpredictable. For reasons unknown, I have witnessed builds that complete successfully and builds that fail midway through, complaining of being unable to write to memory, e.g. 'The instruction at "0x0f048d8a" referenced memory at "0x01340ffc". The memory could not be "written".' The failures occur at various places in builds done from the same location. There was nothing different that was done between the successes and failures, aside from being in a different 'DOS box'. Per the guru-help request, 'ENVIRON.TXT' is attached and ' go32-v2' yielded go32/v2 version 2.0 built Dec 24 1999 17:46:57 Usage: go32 coff-image [args] Rename this to go32.exe only if you need a go32 that can run v2 binaries as well as v1 binaries (old makefiles). Put ahead of the old go32 in your PATH but do not delete your old go32 - leave it in the PATH after this one. Set GO32_V2_DEBUG=y in the environment to get verbose output. DPMI memory available: 77748 Kb DPMI swap space available: 0 Kb There are no CONFIG.SYS or AUTOEXEC.BAT files to include. Next, while make resolves and builds a filename larger than 8.3, for some reason other rules won't work against these files. And this is with 'LFN=y' in the DJGPP.ENV file. For example, the rule %.aso: %.as asc $*.as $(OPT_AS_COMPILE) will build 'reactions.as', producing 'reactions.aso'. This object file is then included in the link rule $(TRG_AGRUNT): $(OBJ_AGRUNT) asl $(OPT_AS_LINK) -o $@ $^ which produces the command-line (emphasis added) asl -v -o agrunt.asd stiffarm.aso lateral.aso hits.aso qb.aso idle.aso run.aso lineup.aso getup.aso tackles.aso catches.aso throw.aso taunts.aso mills.aso victory.aso huddle.aso blocks.aso kicks.aso reactions.aso hurdles.aso which then aborts the build with a link error. If this same line is simply entered to the command-line, the link is successful. Also, the 'clean' rule process $(foreach VAR,$(TRGS_CLN),@if exist $(VAR) $(RM) $(VAR)$(NEWLINE)) will not remove 'reactions.aso', though the 'if' is executed against this file. And again, if entered as a command, this 'if' will remove the file. When checked with a -n, these problem lines are correctly displayed, but it seems that the filename is being truncated to 8.3 (but not with the implicit build rule). Last, the most mysterious problem of all. I have no idea why TRGS := ball.$(RTD) OBJS := $(TRGS:.$(RTD)=.$(TDL)) SRCS := $(TEXS) .PRECIOUS: $(OBJS) #--------------------------------------- # Make specified targets. #--------------------------------------- all: $(TRGS) @echo $(MSG_MAKING) $(MSG_DIR) $(MSG_COMPLETE) %.$(RTD): %.$(TDL) $(SRCS) @$(GNTEXTDT) $< %.$(TDL): $(SRCS) @$(GENTLOAD) $* causes make to error-out with "make.exe: *** No rule to make target `ball.RTD', needed by `all'. Stop." Looks to me like the rule is right there, and this *exact* set of rules works fine in other makefiles. I hope this helps determine what problem(s) I am having. I am truly in the dark as to where to go next; wish linux was an option. And while there may not be any immediate solutions, may I at least bother for an acknowledgement to this, as there is a fair quantity of development-pressure on my end (as if THAT was anything new). Thank you for your attention. Daniel Jon Thompson dthompso AT midwaygames DOT com danielt55 AT earthlink DOT net Desk 773.961.2783 Cell 847.571.6450 Home 847.623.9418 ICQ# 109159992 ------_=_NextPart_001_01C0AE5C.83230AF0 Content-Type: text/html; charset="iso-8859-1"
HELP!
 
I have been writing makefiles to run under djgpp; GNU-make, including the djgpp iteration, blows away NMAKE (no big news flash here).  I know that it may be a problem running djgpp under command-line CMD.EXE in Windows 2000, but that is the environment the MS-heads here have selected.  I have been having quite a series of problems and inconsistencies, e.g. moving from make 3.73 to 3.79.1, but have resolved most of them.  I have just slammed into a wall, though.
 
The project that is being configured to build with GNU-make is a decent-size directory tree.  The build-tree has been set up to fully recurse from any location in the tree.  Herein lies one of the major inconsistencies: when doing a build from the root of the tree (or any sufficiently large branch), the results are unpredictable.  For reasons unknown, I have witnessed builds that complete successfully and builds that fail midway through, complaining of being unable to write to memory, e.g. 'The instruction at "0x0f048d8a" referenced memory at "0x01340ffc".  The memory could not be "written".'  The failures occur at various places in builds done from the same location.  There was nothing different that was done between the successes and failures, aside from being in a different 'DOS box'.  Per the guru-help request, 'ENVIRON.TXT' is attached and ' go32-v2' yielded
 
go32/v2 version 2.0 built Dec 24 1999 17:46:57
Usage: go32 coff-image [args]
Rename this to go32.exe only if you need a go32 that can run v2 binaries as
 well as v1 binaries (old makefiles).  Put ahead of the old go32 in your PATH
 but do not delete your old go32 - leave it in the PATH after this one.
Set GO32_V2_DEBUG=y in the environment to get verbose output.
 
DPMI memory available: 77748 Kb
DPMI swap space available: 0 Kb
 
There are no CONFIG.SYS or AUTOEXEC.BAT files to include.
 
Next, while make resolves and builds a filename larger than 8.3, for some reason other rules won't work against these files.  And this is with 'LFN=y' in the DJGPP.ENV file.  For example, the rule
 
%.aso: %.as
    asc $*.as $(OPT_AS_COMPILE)
 
will build 'reactions.as', producing 'reactions.aso'.  This object file is then included in the link rule
 
$(TRG_AGRUNT): $(OBJ_AGRUNT)
    asl $(OPT_AS_LINK) -o $@ $^
 
which produces the command-line (emphasis added)
 
    asl -v -o agrunt.asd stiffarm.aso lateral.aso hits.aso qb.aso idle.aso run.aso lineup.aso getup.aso tackles.aso catches.aso throw.aso taunts.aso mills.aso victory.aso huddle.aso blocks.aso kicks.aso reactions.aso hurdles.aso
 
which then aborts the build with a link error.  If this same line is simply entered to the command-line, the link is successful.  Also, the 'clean' rule process
 
    $(foreach VAR,$(TRGS_CLN),@if exist $(VAR) $(RM) $(VAR)$(NEWLINE))
 
will not remove 'reactions.aso', though the 'if' is executed against this file.  And again, if entered as a command, this 'if' will remove the file.  When checked with a -n, these problem lines are correctly displayed, but it seems that the filename is being truncated to 8.3 (but not with the implicit build rule).
 
Last, the most mysterious problem of all.  I have no idea why
 
TRGS := ball.$(RTD)
 
OBJS := $(TRGS:.$(RTD)=.$(TDL))
 
SRCS := $(TEXS)
 
.PRECIOUS: $(OBJS)
 
#---------------------------------------
# Make specified targets.
#---------------------------------------
all: $(TRGS)
    @echo $(MSG_MAKING) $(MSG_DIR) $(MSG_COMPLETE)
 
%.$(RTD): %.$(TDL) $(SRCS)
    @$(GNTEXTDT) $<
 
%.$(TDL): $(SRCS)
    @$(GENTLOAD) $*
causes make to error-out with "make.exe: *** No rule to make target `ball.RTD', needed by `all'.  Stop."  Looks to me like the rule is right there, and this *exact* set of rules works fine in other makefiles.
 
I hope this helps determine what problem(s) I am having.  I am truly in the dark as to where to go next; wish linux was an option.  And while there may not be any immediate solutions, may I at least bother for an acknowledgement to this, as there is a fair quantity of development-pressure on my end (as if THAT was anything new).
 
Thank you for your attention.
 
Daniel Jon Thompson
dthompso AT midwaygames DOT com
danielt55 AT earthlink DOT net
Desk 773.961.2783
Cell 847.571.6450
Home 847.623.9418
ICQ# 109159992
 
------_=_NextPart_001_01C0AE5C.83230AF0-- ------_=_NextPart_000_01C0AE5C.83230AF0 Content-Type: text/plain; name="environ.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="environ.txt" ALLUSERSPROFILE=3DC:\Documents and Settings\All Users APPDATA=3DC:\Documents and Settings\dthompso\Application Data ART_INCS=3Denvvar.mak command.mak ART_ROOT=3DC:\ARTWORK BLITZ=3DC:\Blitz BLITZ_DEL=3Ddel /F /Q ClassPath=3DC:\WINNT\system32;C:\WINNT\System32\Wbem;C:\WINNT\Java\Class= es\RxAssistant.zip CommonProgramFiles=3DC:\Program Files\Common Files COMPUTERNAME=3DDTHOMPSO ComSpec=3DC:\WINNT\system32\cmd.exe DIRCMD=3D/ogen DJGPP=3DC:\DJGPP\DJGPP.ENV GS_PLATFORM=3DRWPC HOMEDRIVE=3DC: HOMEPATH=3D\ INC2D_DIR=3DC:\Blitz\blitz\inc2d INCS_DIR=3DC:\Blitz\blitz\incs LOGONSERVER=3D\\MWYUSER1 NUMBER_OF_PROCESSORS=3D1 OS=3DWindows_NT Os2LibPath=3DC:\WINNT\system32\os2\dll; Path=3DC:\djgpp\bin;C:\;C:\Perl\bin\;C:\WINNT\system32;C:\WINNT;C:\WINNT= \System32\Wbem;C:\Program Files\Dell\Resolution = Assistant\Common\bin;C:\Blitz\Art\tools;X:.;W:.;Z:.;Y:. PATHEXT=3D.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH PROCESSOR_ARCHITECTURE=3Dx86 PROCESSOR_IDENTIFIER=3Dx86 Family 6 Model 8 Stepping 6, GenuineIntel PROCESSOR_LEVEL=3D6 PROCESSOR_REVISION=3D0806 ProgramFiles=3DC:\Program Files PROMPT=3D$P$G SystemDrive=3DC: SystemRoot=3DC:\WINNT TARGET_DIR=3DL:\ TEMP=3DC:\DOCUME~1\dthompso\LOCALS~1\Temp TMP=3DC:\DOCUME~1\dthompso\LOCALS~1\Temp USERDOMAIN=3DUSER USERNAME=3DDThompso USERPROFILE=3DC:\Documents and Settings\dthompso windir=3DC:\WINNT ------_=_NextPart_000_01C0AE5C.83230AF0--