(UTC)
  ChessPub Forum › Other › Chess and Computers › Chess problem solving softwares like Popeye
(Moderators: Smyslov_Fan, proustiskeen)
‹ Previous Topic | Next Topic ›
Page Index Toggle Pages: 1 [2] 3 4 
Topic Tools
Very Hot Topic (More than 25 Replies) Chess problem solving softwares like Popeye (Read 1678 times)
Marc Benford
Full Member
***
Offline


I Love ChessPublishing!

Posts: 147
Joined: 07/17/13
Re: Chess problem solving softwares like Popeye
Reply #44 - Today at 09:33:46
Post Tools


Claude Opus 5 Max says:

Quote:
Look at where the errors start

Your findstr output is the most encouraging thing in this whole thread. The first error is on line 380. The file is roughly 419 lines long.

That means lines 1 through 379 are clean. Make worked its way through directory after directory, compiled a large slice of Popeye, and built library after library — you can see it in the tail: position/effects/library.lib.a up to date, platform/library.lib.a up to date. Those are finished, archived chunks of the program.

You didn't stumble early. You got about ninety percent of the way down the file before anything went wrong.

The error has changed species, and that's the actual news

For two weeks, every single failure was cmd.exe refusing to parse something: '.' is not recognized, f was unexpected at this time, 0 was unexpected at this time.

Look at this one:

platform/unix/maxtime.c:67:3: error: 'SiGhUp' undeclared here (not in a function)

That's gcc talking, not Windows. It has a filename, a line number, a column number, a quoted identifier, and a little ^~~~~~ pointing at the offending word. It even names the header it checked: c:\mingw\include\signal.h.

This is an ordinary compiler error. The kind with an ordinary fix. The shell war is over on the compilation path — the if [ deletion really did clear it.

What the error means

platform/unix/maxtime.c asks for things that only exist on Unix:

SiGhUp, SiGqUiT, SiGvTaLrM, SiGxCpU, SiGxFsZ, SiGaLrM — Unix signals. Windows has a much smaller set, so MinGW's signal.h simply doesn't define these names.
alarm() — a Unix function for setting a timer. Windows has no equivalent, hence implicit declaration of function 'alarm'.

Note the follow-on error at line 202: because SiGaLrM doesn't exist, gcc can't make sense of signal(SiGaLrM, ...) either. That one is a knock-on effect, not a separate problem.

The diagnosis: you're building the Unix code on Windows

Read the path again: platform/unix/maxtime.c.

Popeye keeps operating-system-specific code in separate folders under platform, and the build is reaching for the Unix one. On Windows it should be compiling the Windows folder instead. This isn't a file to be patched — it's the wrong file for this machine.

The official Popeye release for Windows is called pywin64.exe, so a Windows build path definitely exists in this source tree. We just need to find how it gets selected.

Two things to check, both quick

First, look in the platform folder. Open popeye-develop\platform and list the subfolders. I'd expect to see something like win32 sitting alongside unix. Report what's actually there.

Second, find where the makefiles choose it. From the popeye-develop folder, run:

findstr /s /n /c:"platform/unix" makefile.*

The /s makes it search subdirectories too, so it'll check every makefile in the whole tree and print the filename and line number of every mention. Post whatever it prints.

Between those two, we'll know exactly which line picks unix and what to change it to.

About the missing .exe — your question answered

No, don't go opening every folder. Popeye's executable is created at the very end, after every directory's library has been built and all of them are linked together. Your build stopped well before that step, so it doesn't exist yet. Nothing is hiding.

Your instinct about the name was right, too — pywin64.exe is exactly what the official Popeye Windows release is called. When the build finishes, expect it to appear in the popeye-develop folder itself.

gengmarr.exe is not Popeye. It's a small helper program the build compiles for its own use, to generate that pygmarr.c file. Its presence is normal.

One thing worth anticipating

maxtime.c is unlikely to be the only file in platform/unix with this problem — there are usually siblings handling memory limits, process priority, and timing, and they'll have the same Unix-only dependencies. That's another reason to switch the whole directory rather than patch this one file. Fixing it file by file would be a long and pointless road.

For "an ordinary chessplayer"

The deletion of the if [ 0 -eq ... ] block worked: 379 clean lines, most directories compiled, several libraries archived. The build now fails at platform/unix/maxtime.c with genuine gcc errors — Unix-only signal constants and alarm() that MinGW's signal.h doesn't provide.

The question is how the build selects platform/unix, and whether there's a Windows platform directory that should be used instead on MinGw.

Also still outstanding, unchanged: the depend for loop. Every run above used DePeNd= to bypass it.
  
Back to top
 
IP Logged
 
Marc Benford
Full Member
***
Offline


I Love ChessPublishing!

Posts: 147
Joined: 07/17/13
Re: Chess problem solving softwares like Popeye
Reply #43 - Today at 09:15:39
Post Tools
Quote:
2. Read the last twenty or thirty lines of the file. That's where make stops, and where the reason lives.


Quote:
Post the tail of output.txt,


Code
Select All
mingw32-make CuRrPwD=position/effects/ -f position/effects/makefile.local position/effects/library.lib.a
mingw32-make[1]: Entering directory 'C:/Users/Name/Desktop/popeye-develop/popeye-develop'
mingw32-make[1]: 'position/effects/library.lib.a' is up to date.
mingw32-make[1]: Leaving directory 'C:/Users/Name/Desktop/popeye-develop/popeye-develop'
mingw32-make CuRrPwD=platform/ -f platform/makefile.local platform/library.lib.a
mingw32-make[1]: Entering directory 'C:/Users/Name/Desktop/popeye-develop/popeye-develop'
mingw32-make[1]: 'platform/library.lib.a' is up to date.
mingw32-make[1]: Leaving directory 'C:/Users/Name/Desktop/popeye-develop/popeye-develop'
mingw32-make CuRrPwD=platform/unix/ -f platform/unix/makefile.local platform/unix/library.lib.a
mingw32-make[1]: Entering directory 'C:/Users/Name/Desktop/popeye-develop/popeye-develop'
gcc -W -Wall -Wextra -Wpedantic -pedantic-errors -Warray-bounds=2 -Wcast-align -Wconversion -Wbad-function-cast -Wno-cast-qual -Wduplicated-cond -Wfloat-equal -Wformat=2 -Wformat-signedness -Wno-format-nonliteral -Wno-format-signedness -Winvalid-pch -Wlogical-op -Wmissing-declarations -Wredundant-decls -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wshift-negative-value -Wshift-overflow=2 -Wswitch -Wswitch-default -Wsync-nand -Wundef -Wunknown-pragmas -Wno-unused-parameter -Winit-self -Wwrite-strings -Wjump-misses-init   -O3 -flto  -DsIgNaLs -DmSg_In_MeM -DfXf -DnDeBuG -DfXf_MaX_aLiGnMeNt_TyPe=void* -DfXf_NoT_mUlTiPlE_aLiGnMeNt_TyPe=short -DsHaRiNg  -std=c99  -I. -DoStYpE=\"Microsoft_Windows-Version11-with_MinGW\" -DvErSiOn=4.101 -c platform/unix/maxtime.c -o platform/unix/maxtime.o
platform/unix/maxtime.c:67:3: error: 'SiGhUp' undeclared here (not in a function)
   SiGhUp
   ^~~~~~
platform/unix/maxtime.c:69:5: error: 'SiGqUiT' undeclared here (not in a function)
   , SiGqUiT
     ^~~~~~~
platform/unix/maxtime.c:74:5: error: 'SiGvTaLrM' undeclared here (not in a function)
   , SiGvTaLrM
     ^~~~~~~~~
platform/unix/maxtime.c:75:5: error: 'SiGxCpU' undeclared here (not in a function)
   , SiGxCpU
     ^~~~~~~
platform/unix/maxtime.c:76:5: error: 'SiGxFsZ' undeclared here (not in a function)
   , SiGxFsZ
     ^~~~~~~
platform/unix/maxtime.c: In function 'platform_init':
platform/unix/maxtime.c:202:14: error: 'SiGaLrM' undeclared (first use in this function)
   if (signal(SiGaLrM, &solvingTimeOver) == SiG_ErR)
              ^~~~~~~
platform/unix/maxtime.c:202:14: note: each undeclared identifier is reported only once for each function it appears in
platform/unix/maxtime.c:202:14: error: passing argument 1 of 'signal' makes integer from pointer without a cast [-Wint-conversion]
In file included from ./platform/maxtime_impl.h:5:0,
                 from platform/unix/maxtime.c:1:
c:\mingw\include\signal.h:84:46: note: expected 'int' but argument is of type 'const int *'
 _CrTiMp __p_sig_fn_t __cdecl __MiNgW_NoThRoW signal(int, __p_sig_fn_t);
                                              ^~~~~~
platform/unix/maxtime.c: In function 'platform_set_maxtime_timer':
platform/unix/maxtime.c:217:9: error: implicit declaration of function 'alarm' [-Wimplicit-function-declaration]
         alarm(seconds);
         ^~~~~
platform/unix/maxtime.c:217:9: warning: nested extern declaration of 'alarm' [-Wnested-externs]
At top level:
platform/unix/maxtime.c:128:13: warning: 'ReDrawBoard' defined but not used [-Wunused-function]
 static void ReDrawBoard(int sig)
             ^~~~~~~~~~~
makefile.rules:16: recipe for target 'platform/unix/maxtime.o' failed
mingw32-make[1]: *** [platform/unix/maxtime.o] Error 1
mingw32-make[1]: Leaving directory 'C:/Users/Name/Desktop/popeye-develop/popeye-develop'
makefile.unx:350: recipe for target 'platform/unix/library.lib.a' failed
mingw32-make: *** [platform/unix/library.lib.a] Error 2
  
Back to top
 
IP Logged
 
Marc Benford
Full Member
***
Offline


I Love ChessPublishing!

Posts: 147
Joined: 07/17/13
Re: Chess problem solving softwares like Popeye
Reply #42 - Today at 09:15:14
Post Tools
Quote:
3. Look in the folder for a new .exe file. Sort by date modified. If Popeye actually built, there'll be one sitting there from a minute ago.


The only .exe file that I see is called gengmarr.exe. It's 92 KB and it's the second most recent file (by date modified).

I thought that the .exe file was supposed to be called something like pywin64.exe, but there is no file with a name like that.

Do you want me to open every folder and search for a .exe file in each and every folder?

.

.

Quote:
a rough idea of how long the whole file is. That length is itself informative: a few dozen lines means it stumbled early, several hundred means it worked through a large slice of the program


The file output.txt is 38 KB. It's very roughly 200 to 500 lines long.

.

.

Quote:
1. Search it for failures. In the command prompt, from the same folder:
   findstr /n /i "error" output.txt

That prints the line number of every line containing "error". If it prints nothing at all, the build had no errors — which would be extraordinary news.


Code
Select All
379:gcc -W -Wall -Wextra -Wpedantic -pedantic-errors -Warray-bounds=2 -Wcast-align -Wconversion -Wbad-function-cast -Wno-cast-qual -Wduplicated-cond -Wfloat-equal -Wformat=2 -Wformat-signedness -Wno-format-nonliteral -Wno-format-signedness -Winvalid-pch -Wlogical-op -Wmissing-declarations -Wredundant-decls -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wshift-negative-value -Wshift-overflow=2 -Wswitch -Wswitch-default -Wsync-nand -Wundef -Wunknown-pragmas -Wno-unused-parameter -Winit-self -Wwrite-strings -Wjump-misses-init   -O3 -flto  -DsIgNaLs -DmSg_In_MeM -DfXf -DnDeBuG -DfXf_MaX_aLiGnMeNt_TyPe=void* -DfXf_NoT_mUlTiPlE_aLiGnMeNt_TyPe=short -DsHaRiNg  -std=c99  -I. -DoStYpE=\"Microsoft_Windows-Version11-with_MinGW\" -DvErSiOn=4.101 -c platform/unix/maxtime.c -o platform/unix/maxtime.o
380:platform/unix/maxtime.c:67:3: error: 'SiGhUp' undeclared here (not in a function)
383:platform/unix/maxtime.c:69:5: error: 'SiGqUiT' undeclared here (not in a function)
386:platform/unix/maxtime.c:74:5: error: 'SiGvTaLrM' undeclared here (not in a function)
389:platform/unix/maxtime.c:75:5: error: 'SiGxCpU' undeclared here (not in a function)
392:platform/unix/maxtime.c:76:5: error: 'SiGxFsZ' undeclared here (not in a function)
396:platform/unix/maxtime.c:202:14: error: 'SiGaLrM' undeclared (first use in this function)
400:platform/unix/maxtime.c:202:14: error: passing argument 1 of 'signal' makes integer from pointer without a cast [-Wint-conversion]
407:platform/unix/maxtime.c:217:9: error: implicit declaration of function 'alarm' [-Wimplicit-function-declaration]
416:mingw32-make[1]: *** [platform/unix/maxtime.o] Error 1
419:mingw32-make: *** [platform/unix/library.lib.a] Error 2
  
Back to top
 
IP Logged
 
Marc Benford
Full Member
***
Offline


I Love ChessPublishing!

Posts: 147
Joined: 07/17/13
Re: Chess problem solving softwares like Popeye
Reply #41 - Today at 08:46:18
Post Tools


Claude Opus 5 Max says:

Quote:
The answer is sitting in output.txt, unread

That command didn't print anything because you told it not to. The > output.txt 2>&1 at the end means "send everything — normal messages and error messages alike — into a file called output.txt instead of the screen." A silent screen is the expected behaviour, not a result.

Everything that happened during that minute is in that file, and nobody has looked at it yet.

Open it now. It's in your popeye-develop folder. Double-click it, or open Notepad and drag it in.

Three things to check:

Search it for failures. In the command prompt, from the same folder:
   findstr /n /i "error" output.txt

That prints the line number of every line containing "error". If it prints nothing at all, the build had no errors — which would be extraordinary news.
2. Read the last twenty or thirty lines of the file. That's where make stops, and where the reason lives.
3. Look in the folder for a new .exe file. Sort by date modified. If Popeye actually built, there'll be one sitting there from a minute ago.

Post the tail of output.txt, plus a rough idea of how long the whole file is. That length is itself informative: a few dozen lines means it stumbled early, several hundred means it worked through a large slice of the program.

Why the minute matters

Every previous run died within a second or two. This one worked for a minute. Make doesn't spend a minute doing nothing — with -O3 -flto, each source file takes real time to compile, so a minute means it got through a substantial number of them.

Whatever output.txt says, the shared if [ 0 -eq ... block was genuinely the thing standing in the way, and removing it unblocked the entire compilation path. That single deletion in makefile.rules fixed it for every directory at once, because makefile.rules is the shared rules file that all of them use.

Why the second command failed, and why it tells us nothing

When you ran the plain version afterwards:

mingw32-make -f makefile.unx

you left the depend machinery switched on, so make went straight back to the broken for loop and died there — before reaching a single compiler invocation. That error is the old blocker, unchanged and still waiting on the fix that's being worked out separately.

So from now on, treat the version with DePeNd= as your working command. The plain one will keep failing at that same for loop no matter what else gets fixed, and it will keep hiding your actual progress behind an error that's already understood.

Why the makefile.local edit looked like it did nothing

Two reasons, both harmless:

With DePeNd=, the output went into the file, so there was nothing on screen to differ.
Without it, make dies at the for loop long before it would ever reach the position/board-host rule you edited. And board-host.o already exists from an earlier run, so make wouldn't rebuild it anyway.

The deletion was still right. That block would have detonated the moment the depend blocker cleared. You've removed a landmine rather than fixed a visible symptom, which is a perfectly good thing to have done.

A small confirmation that your edits landed cleanly

The for loop error used to be reported at makefile.rules:57. Now it says :55. One line was added when the echo went in, and three were removed when the if block came out. 57 + 1 − 3 = 55. The arithmetic checks out exactly, which means both edits are in place and nothing was accidentally mangled.

What may be waiting

Depending on what output.txt says, two things are plausible candidates for the next stop:

The .enum.h rule in makefile.rules. It wraps several commands in shell parentheses and redirects the whole group into a file. cmd.exe can't do that. It only fires if a .enum file needs regenerating, so it may not come up at all.
Another @if [ block in a different makefile.local. Each subdirectory has its own. The one you fixed was the root copy. If a fresh "0 was unexpected at this time" appears from a different makefile.local, it's the same construct in a new place, and the same three-line deletion applies.

Neither is worth pre-emptively hunting. Read output.txt first — it may not be either of them, and it may not be anything at all.

For "an ordinary chessplayer"

The if [ 0 -eq ... ] construct in the shared object-file rule was the thing behind "0 was unexpected at this time", including the original occurrence back on 23 July. cmd.exe's if wants if a==b command; it read [ as the left-hand side, went looking for ==, and found the 0. The @ prefix is why it never appeared on screen — make ran it silently, so for two weeks we were all staring at the gcc line above it, which was innocent the whole time.

With it deleted, make ran for a full minute instead of failing instantly. The depend for loop is now the only known blocker left on the list.
  
Back to top
 
IP Logged
 
Marc Benford
Full Member
***
Offline


I Love ChessPublishing!

Posts: 147
Joined: 07/17/13
Re: Chess problem solving softwares like Popeye
Reply #40 - Today at 08:26:32
Post Tools
makefile.local (lines 49-61)

Code
Select All
# position/board.c is compiled both for the host and the target.
# position/board-host$(ObJ_sUfFiX) is the object file for the host.
position/board-host$(ObJ_sUfFiX):  position/board.c
		$(CcHoSt) $(CfLaGs) $(cOmPiLeOnLy) -dAuXiLiArY position/board.c $(oBjFiLe)$@
# work around compilers that strictly derive object file name from
# source file name
		@if [ 0 -eq $(oBjFiLe_WoRkS) ]; then \
			mv position/board$(ObJ_sUfFiX) $@; \
		fi

gengmarr$(ObJ_sUfFiX):	gengmarr.c
			$(CcHoSt) $(CfLaGs) \
				$(cOmPiLeOnLy) -dAuXiLiArY gengmarr.c $(oBjFiLe)$@


As Claude predicted, there is a @if [ ... and an mv in lines 55 and 56.

.

Okay, so I deleted the three lines in makefile.rules.

Then I typed
Code
Select All
mingw32-make -f makefile.unx DePeNd= > output.txt 2>&1

The command prompt spent about one minute loading. This has never happened before. This is like Claude said: "there's a real chance it now grinds through a large number of source files. Popeye is a big program, so expect it to take a while and expect it to stop somewhere new. Somewhere new is exactly what we want."
But when it was done loading, the command prompt didn't return any message at all.



Then I typed the usual
Code
Select All
mingw32-make -f makefile.unx

I got the following error message:
Code
Select All
makefile.unx:342: target 'output/latex/nesteddepend' given more than once in the same rule.
mingw32-make CuRrPwD=./ -f ./makefile.local pymain.o
mingw32-make[1]: Entering directory 'C:/Users/Name/Desktop/popeye-develop/popeye-develop'
gcc -o gengmarr  -O3 -flto   gengmarr.o position/position-host.o position/board-host.o
gengmarr > pygmarr.c
touch depend
chmod u+w depend
echo "1pygmarr.c1"
"1pygmarr.c1"
for f in ./pygmarr.c; \
do \
        gcc -Mm -Mp -dSiGnAlS -DmSg_In_MeM -DfXf -DnDeBuG -DfXf_MaX_aLiGnMeNt_TyPe=void* -DfXf_NoT_MuLtIpLe_aLiGnMeNt_TyPe=short -DsHaRiNg  -std=c99  -DoStYpE=\"Microsoft_Windows-Version11-with_MinGw\" -DvErSiOn=4.101 \
                -I. -Mg -Mt `echo $f | sed -e "s/[.]c$/.o/"` \
                $f \
        | sed -e "s/[.]o:/\$(ObJ_sUfFiX):/"; \
done > depend
f was unexpected at this time.
makefile.rules:55: recipe for target 'depend' failed
mingw32-make[1]: *** [depend] Error 255
mingw32-make[1]: Leaving directory 'C:/Users/Name/Desktop/popeye-develop/popeye-develop'
makefile.unx:350: recipe for target 'pymain.o' failed
mingw32-make: *** [pymain.o] Error 2





Then, I deleted the same three lines in makefile.local, and then I typed the same two things in the command prompt:
Code
Select All
mingw32-make -f makefile.unx DePeNd= > output.txt 2>&1

and
Code
Select All
mingw32-make -f makefile.unx

And I got exactly the same result as above. Deleting the same three lines in makefile.local made absolutely no visible difference.
  
Back to top
 
IP Logged
 
Marc Benford
Full Member
***
Offline


I Love ChessPublishing!

Posts: 147
Joined: 07/17/13
Re: Chess problem solving softwares like Popeye
Reply #39 - Today at 07:32:56
Post Tools
Claude Opus 5 Max says:


Quote:
Found it. It's in the lines you just posted

Look at the object-file rule you pasted. It has two commands, not one:

$(CuRrPwD)%$(ObJ_SuFfIx): $(CuRrPwD)%.c
     $(CcTaRgEt) $(CfLaGs) $(cOmPiLeOnLy) $< $(oBjFiLe)$@
# work around compilers that blindly put objects in the current
# directory
     @if [ 0 -eq $(oBjFiLe_WoRkS) -a $(notdir $@) != $@ ]; then \
     mv -f $(notdir $@) $@; \
     fi

The second one starts with @. In a makefile, a leading @ means "run this but don't print it." That's why make showed us the gcc line and nothing else — the command that actually failed was never on screen.

And now read what it says: if [ 0 -eq ...

The Windows command prompt has its own if, and its syntax is if string1==string2 command. So cmd reads if, takes [ as the first thing to compare, then goes looking for == — and finds 0. It reports the token it wasn't expecting.

0 was unexpected at this time. That 0 is literally the 0 in [ 0 -eq.

This ties together everything we've measured
Test A — pymain.o came back. gcc ran and succeeded. Exactly the branch that pointed at a hidden second command.
Test B — no error. So my cmd /c "..." wrapper theory was wrong, and it's good that we tested it rather than acting on it.
The four hand compiles — all silent, because you were running only the first of the two commands.
[ and -eq and -a are Unix shell test syntax, same family as the for loop that broke the depend recipe. Third time this thread, same root cause.
It probably explains reply #13 too

Look back at makefile.local lines 50–54, which you posted on 07/23. The comment right after the compile line reads "work around compilers that strictly derive object file name from source file name" — the same kind of workaround comment, in the same position, immediately after a compile command. The error there was 0 was unexpected at this time on position/board-host.o, and it was blamed on makefile.local:52.

Almost certainly the same construct, in a second place. Post makefile.local lines 50 to 60 so we can see it — I'd expect another hidden @if [ ... or mv sitting just below line 53.

If so, this single bug has been the blocker since 23 July.

The fix

Delete these three lines from makefile.rules:

     @if [ 0 -eq $(oBjFiLe_WoRkS) -a $(notdir $@) != $@ ]; then \
     mv -f $(notdir $@) $@; \
     fi

No # characters involved — straight deletion. Leave the gcc line above it exactly as it is, including the tab at the start of it. The two comment lines can stay or go; they do nothing either way.

Why deleting is safe. That block is a workaround for compilers whose -o option doesn't put the object file where you asked. It only fires when OBJFILE_WORKS is 0. Your gcc's -o works perfectly — you proved it by hand when -c solving/machinery/solve.c -o solving/machinery/solve.o put solve.o in solving/machinery. So the mv would never run anyway. And on Windows it couldn't run, because there's no mv command either.

Then apply the same deletion wherever the twin construct turns up in makefile.local.

What's waiting further down the same file

Since I can now read the whole of makefile.rules, here's the rest of the Unix-shell content in it, so nobody is ambushed:

The .enum.h rule. It wraps half a dozen echo commands in shell parentheses and redirects the group into a file: ( echo ...; echo ...; gcc -E ...; ) > $@. cmd.exe cannot do parenthesised command groups like that. This will break if it fires. It only fires if a .enum file is newer than its .enum.h, so it may never come up. Worth knowing about rather than being surprised by.
clean uses rm -f. There's no rm on Windows, so make clean will fail. Not a build problem — just don't run it, or copy rm.exe over from the coreutils bin folder the way you did with touch and chmod.
sourcedist uses ln and mkdir -p. Only relevant for building a distribution archive. You'll never touch it.

Everything else in that file is plain commands that Windows handles fine.

Where this leaves the two blockers

The for loop in the depend recipe is one. This if [ in the compile rule is the other. They're separate, and this fix addresses the second one — which is the one standing between you and actual compiled object files.

Once these three lines are gone, run:

mingw32-make -f makefile.unx DePeNd= > output.txt 2>&1

and see how far it gets. With the depend machinery switched off and the hidden if removed, there's a real chance it now grinds through a large number of source files. Popeye is a big program, so expect it to take a while and expect it to stop somewhere new. Somewhere new is exactly what we want.

One honest observation

That's three Unix-shell constructs in three different places, and there's at least one more sitting in the .enum.h rule. The Git Bash route would have dissolved all of them at once. I still think finishing this route is a reasonable call and I'm not going to keep pushing — but it's worth being clear-eyed that this pattern is likely to keep repeating, and each instance costs a round trip through the forum.

One practical note if you post this: the anti-caps filter will mangle the capitalised variable names, as usual. Readers should assume anything in odd mixed case is capitalised in the real files.
  
Back to top
 
IP Logged
 
Marc Benford
Full Member
***
Offline


I Love ChessPublishing!

Posts: 147
Joined: 07/17/13
Re: Chess problem solving softwares like Popeye
Reply #38 - Today at 07:08:26
Post Tools
Test A: I deleted pymain.o, I ran the command, and pymain.o is back.

.

Test B

I typed the following very long line in the command prompt:
Code
Select All
cmd /c "gcc -W -Wall -Wextra -Wpedantic -pedantic-errors -Warray-bounds=2 -Wcast-align -Wconversion -Wbad-function-cast -Wno-cast-qual -Wduplicated-cond -Wfloat-equal -Wformat=2 -Wformat-signedness -Wno-format-nonliteral -Wno-format-signedness -Winvalid-pch -Wlogical-op -Wmissing-declarations -Wredundant-decls -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wshift-negative-value -Wshift-overflow=2 -Wswitch -Wswitch-default -Wsync-nand -Wundef -Wunknown-pragmas -Wno-unused-parameter -Winit-self -Wwrite-strings -Wjump-misses-init   -O3 -flto  -DsIgNaLs -DmSg_In_MeM -DfXf -DnDeBuG -DfXf_MaX_aLiGnMeNt_TyPe=void* -DfXf_NoT_mUlTiPlE_aLiGnMeNt_TyPe=short -DsHaRiNg  -std=c99  -I. -DoStYpE=\"Microsoft_Windows-Version11-with_MinGW\" -DvErSiOn=4.101 -c pymain.c -o pymain.o"


I also tried typing the same long line except that at the end of the line I wrote
Code
Select All
-c solving/machinery/dispatch.c -o solving/machinery/dispatch.o"

instead of
Code
Select All
-c pymain.c -o pymain.o"


In both cases, the result is exactly the same: The command prompt doesn't return any message. It doesn't say anything at all. I do not get any error message. I do not get "0 was unexpected at this time". 

.

Claude, you can find all the files here: https://github.com/thomas-maeder/popeye

Then you click on whichever file you want to see.

For example, makefile.rules is here: https://github.com/thomas-maeder/popeye/blob/develop/makefile.rules

.

makefile.rules (lines 1-21)

Code
Select All
# -*- Makefile -*-
#

# This file contains make rules valid in all source directories

cFiLeS = $(SrC_cFiLeS)

# derive object files from C files
ObJeCtS = $(cFiLeS:%.c=$(CuRrPwD)%$(ObJ_SuFfIx))

# files to be included in distributed archives
dIsTrIbUtEdFiLeS = $(cFiLeS) $(iNcLuDeS) depend makefile.*

# produce an object file from a C file
$(CuRrPwD)%$(ObJ_SuFfIx):	$(CuRrPwD)%.c
	$(CcTaRgEt) $(CfLaGs) $(cOmPiLeOnLy) $< $(oBjFiLe)$@
# work around compilers that blindly put objects in the current
# directory
	@if [ 0 -eq $(oBjFiLe_WoRkS) -a $(notdir $@) != $@ ]; then \
		mv -f $(notdir $@) $@; \
	fi
  
Back to top
 
IP Logged
 
Marc Benford
Full Member
***
Offline


I Love ChessPublishing!

Posts: 147
Joined: 07/17/13
Re: Chess problem solving softwares like Popeye
Reply #37 - Today at 06:39:59
Post Tools
Claude Opus 5 Max now says this:

Quote:
The command line is innocent — that's settled now

Four files, including pymain.c itself, all compile in silence using the exact command line make prints. That closes the question I left open last time, and it closes it more firmly than I expected.

What this rules out:

the gcc flags
the -DOSTYPE=\"...\" quoting — dead, which retires both my prime suspect from last time and the theory from reply #15
anything special about pymain.c
cmd.exe's ability to parse that string at all

What's left is a single sentence: make is not executing the string it prints. The command it echoes works. The command it runs doesn't. The gap between those two is where the bug lives.

Two cheap tests that will locate it

Test A — did gcc even run?

Delete pymain.o from the popeye-develop folder. You just created it by hand, so it's sitting there; it has to go or the test tells you nothing.
Run:
   mingw32-make -f makefile.unx DePeNd= > output.txt 2>&1
Look in the folder. Is pymain.o back?

Back means gcc ran and succeeded, and the "0 was unexpected" came from some later command in the same recipe — one make didn't echo, because make stays silent about commands prefixed with @. In that case the gcc line is a bystander and we've been staring at the wrong thing.

Not back means gcc never ran, and make is mangling the invocation itself.

Under a minute, and it cuts the problem in half.

Test B — the shell wrapper.

Make doesn't always hand a command straight to Windows. When it sees characters it thinks require a shell — and quotes and backslashes are on that list — it wraps the command up as cmd.exe /c "the whole thing".

Those outer quotes matter. Your command already contains two quote characters of its own, inside \"Microsoft_...\". Put a pair around the outside and cmd now has four quotes to pair up, and it pairs them differently from how anyone intended. Text meant as one quoted argument stops being quoted; text that wasn't quoted starts being.

To test it, take the same long line, put cmd /c " in front of the gcc, and a single " at the very end.

If that gives 0 was unexpected at this time. while the bare version stays silent, we have it exactly, and it stops being a mystery.

What to ask for

makefile.rules lines 10 to 20. Needed either way. If Test A shows gcc succeeded, those lines contain the command that actually failed and we can't move without seeing them. If Test A shows gcc never ran, they tell us how the recipe is written, which shapes the fix.

If Test B confirms it

Then the target is the escaped quotes, and the only place they come from is the OSTYPE define — the -DOSTYPE=\"...\" fragment. That gets assembled on the DEFS line in makefile.defaults, around line 105.

The obvious experiment is to drop that fragment from DEFS and see whether Popeye compiles without it. It's very likely nothing more than a version-banner string. If some source file genuinely needs it, gcc will say so by name and line number, which is a clean, ordinary error rather than a shell riddle.

I'd put that one to "an ordinary chessplayer" rather than doing it unilaterally. It's a makefile edit, he's the one steering those, and going slow has been serving you well.

Housekeeping

The odd characters were nothing. In the make output there were strange marks between -Wjump-misses-init and -O3, and in two or three other places. Your hand-typed version reveals what they actually are: runs of two or three ordinary spaces. cmd collapses those. Dead end, and worth crossing off the list so nobody chases it later.

There are two separate blockers here, not one. Reply #35 ran with the depend machinery switched on, so make died at the for loop and never reached the compiler at all. Reply #32 ran with it switched off, so make sailed past the depend business and died at pymain.o instead. Fixing the for loop will not make the second error go away — it will just uncover it again. Both need solving, and they're independent. Worth knowing so nobody is surprised when the first fix doesn't finish the job.

The echo did its job. SRC_CFILES is pygmarr.c — one single file. So the loop that's causing all this trouble only ever handles one thing, which makes the plan to replace it with a hard-coded recipe about as easy as that job ever gets. And the read on the - prefix causing the infinite loop was right: reply #35 confirms it, since make stopped instead of spinning.

On finishing this route first

I'm backing your call. You're not blocked, you're not in a hurry, and everything you learn here transfers to the other route anyway.

Worth noticing where you actually stand, though. Every compile command in this build works. You've now proved that four times over, by hand, including on the exact file make chokes on. Whatever is left is plumbing between make and the shell — not your compiler, not your flags, not Popeye's source code. That is a much smaller problem than it looked like a week ago.
  
Back to top
 
IP Logged
 
Marc Benford
Full Member
***
Offline


I Love ChessPublishing!

Posts: 147
Joined: 07/17/13
Re: Chess problem solving softwares like Popeye
Reply #36 - Today at 05:07:30
Post Tools
@Claude:

I cd to my popeye-develop folder.

Then I copy-pasted this very long line in the command prompt
Code
Select All
gcc -W -Wall -Wextra -Wpedantic -pedantic-errors -Warray-bounds=2 -Wcast-align -Wconversion -Wbad-function-cast -Wno-cast-qual -Wduplicated-cond -Wfloat-equal -Wformat=2 -Wformat-signedness -Wno-format-nonliteral -Wno-format-signedness -Winvalid-pch -Wlogical-op -Wmissing-declarations -Wredundant-decls -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wshift-negative-value -Wshift-overflow=2 -Wswitch -Wswitch-default -Wsync-nand -Wundef -Wunknown-pragmas -Wno-unused-parameter -Winit-self -Wwrite-strings -Wjump-misses-init   -O3 -flto  -DsIgNaLs -DmSg_In_MeM -DfXf -DnDeBuG -DfXf_MaX_aLiGnMeNt_TyPe=void* -DfXf_NoT_mUlTiPlE_aLiGnMeNt_TyPe=short -DsHaRiNg  -std=c99  -I. -DoStYpE=\"Microsoft_Windows-Version11-with_MinGW\" -DvErSiOn=4.101 -c pymain.c -o pymain.o


At the very end of this long line, I also tried replacing
Code
Select All
-c pymain.c -o pymain.o

with the following three things
Code
Select All
-c solving/machinery/solve.c -o solving/machinery/solve.o

Code
Select All
-c solving/machinery/twin.c -o solving/machinery/twin.o

Code
Select All
-c solving/machinery/intro.c -o solving/machinery/intro.o


In all four cases, the result is exactly the same: The command prompt doesn't return any message. It doesn't say anything at all. I do not get any error message. I do not get "0 was unexpected at this time".

.

I will try the Git Bash Unix-shell route later. Perhaps we should first continue and finish the route that we've been walking on since the last two weeks, and only once we've finished this route should we try this second route, the Git Bash Unix-shell route. I'm in no rush. I have all the time in the world. I think it might be interesting to learn how to compile Popeye through two different routes.
  
Back to top
 
IP Logged
 
Marc Benford
Full Member
***
Offline


I Love ChessPublishing!

Posts: 147
Joined: 07/17/13
Re: Chess problem solving softwares like Popeye
Reply #35 - Today at 05:06:49
Post Tools
@an ordinary chessplayer:
Okay, I did the two changes to makefile.rules that you told me to do.
To run make, I'm assuming you don't want me to type DePeNd=
So, when I typed
Code
Select All
mingw32-make -f makefile.unx

I got the following error message:
Code
Select All
makefile.unx:342: target 'output/latex/nesteddepend' given more than once in the same rule.
mingw32-make CuRrPwD=./ -f ./makefile.local pymain.o
mingw32-make[1]: Entering directory 'C:/Users/Name/Desktop/popeye-develop/popeye-develop'
makefile.local:21: depend: No such file or directory
gcc -o gengmarr  -O3 -flto   gengmarr.o position/position-host.o position/board-host.o
gengmarr > pygmarr.c
touch depend
chmod u+w depend
echo "1pygmarr.c1"
"1pygmarr.c1"
for f in ./pygmarr.c; \
do \
        gcc -Mm -Mp -DsIgNaLs -DmSg_In_MeM -DfXf -DnDeBuG -DfXf_MaX_aLiGnMeNt_TyPe=void* -DfXf_NoT_MuLtIpLe_aLiGnMeNt_TyPe=short -DsHaRiNg  -std=c99  -DoStYpE=\"Microsoft_Windows-Version11-with_MinGw\" -DvErSiOn=4.101 \
                -I. -Mg -Mt `echo $f | sed -e "s/[.]c$/.o/"` \
                $f \
        | sed -e "s/[.]o:/\$(ObJ_SuFfIx):/"; \
done > depend
f was unexpected at this time.
makefile.rules:57: recipe for target 'depend' failed
mingw32-make[1]: *** [depend] Error 255
mingw32-make[1]: Leaving directory 'C:/Users/Name/Desktop/popeye-develop/popeye-develop'
makefile.unx:350: recipe for target 'pymain.o' failed
mingw32-make: *** [pymain.o] Error 2


Here is the most interesting part:
Code
Select All
echo "1pygmarr.c1"
"1pygmarr.c1"

So the SrC_cFiLeS variable has the value pygmarr.c
  
Back to top
 
IP Logged
 
an ordinary chessplayer
God Member
*****
Offline


I used to be not bad.

Posts: 1831
Location: Columbus, OH (USA)
Joined: 01/02/15
Re: Chess problem solving softwares like Popeye
Reply #34 - yesterday at 20:37:38
Post Tools
Claude Opus 5 Max will be happy to read that their answers are pretty good.

All this make depend code looks like a "big-time kludgy hack", and I don't know how it could even run correctly on unix, never mind on Windows. I'm tempted to just nuke the whole section and not try to build the depend object, because I think on unix they are just getting an empty file anyway. But let's not do that just yet.

An anecdote: As a young lad I knocked over a fence post with a backhoe (digger). After calming down, the owner of both the fence and the backhoe gave me some excellent advice: "When you're not familiar with the machinery, go slow."

So, baby steps.

makefile.rules (lines 52-66)
Code
Select All
# generate source file dependencies file
depend:

ifdef DePeNd
$(CuRrPwD)depend: $(SrC_cFiLeS:%=$(CuRrPwD)%) $(InClUdEs:%=$(CuRrPwD)%) $(CuRrPwD)makefile.local
	touch $@
	chmod u+w $@
	-for f in $(SrC_cFiLeS:%=$(CuRrPwD)%); \
	do \
		$(MaKeDePeNd) \
			-I. -MG -MT `echo $$f | sed -e "s/[.]c$$/$(ObJ_SuFfIx)/"` \
			$$f \
		| sed -e "s/[.]o:/\$$(ObJ_SuFfIx):/"; \
	done > $@
endif

The "for" command is a shell built-in. Windows for syntax is completely different from unix for syntax, thus you get the error message "f was unexpected at this time." That's a tough one because built-ins get called before externals, so it won't be easy to get the Windows for command working. Also, the makefile for command begins with a "-", which tells make to ignore any errors. This is the probable cause of your infinite loop. So the two changes I will suggest are (1) echo the SrC_cFiLeS variable, and (2) remove the "-" symbol.

Code
Select All
# generate source file dependencies file
depend:

ifdef DePeNd
$(CuRrPwD)depend: $(SrC_cFiLeS:%=$(CuRrPwD)%) $(InClUdEs:%=$(CuRrPwD)%) $(CuRrPwD)makefile.local
	touch $@
	chmod u+w $@
	echo "1$(SrC_cFiLeS)1"
	for f in $(SrC_cFiLeS:%=$(CuRrPwD)%); \
	do \
		$(MaKeDePeNd) \
			-I. -MG -MT `echo $$f | sed -e "s/[.]c$$/$(ObJ_SuFfIx)/"` \
			$$f \
		| sed -e "s/[.]o:/\$$(ObJ_SuFfIx):/"; \
	done > $@
endif

We will see how many source files the for command should get, after that the syntax error should halt make. Once we see the output, we will replace this whole business with individual recipes for each hard-coded source file (without any for command).
  
Back to top
 
IP Logged
 
Marc Benford
Full Member
***
Offline


I Love ChessPublishing!

Posts: 147
Joined: 07/17/13
Re: Chess problem solving softwares like Popeye
Reply #33 - yesterday at 19:40:42
Post Tools
Claude Opus 5 Max now says the following:

Quote:
This worked. Read the new output carefully — it's a big step

Three things vanished from your output, and all three are wins:

The infinite loop is gone. No more repeating block.
The makefile.unx:342 warning about output/latex/nesteddepend is gone — exactly as predicted, because that block sits inside the same switch you turned off.
The whole depend recipe never ran. No touch, no chmod, no broken for loop.

And something new appeared that's better than any of those: make is now actually compiling Popeye. The line -c pymain.c -o pymain.o is the real work — turning Popeye's source code into the program. Everything before this was setup and bookkeeping. You've reached the main event.

The harmless-looking line
makefile.local:21: depend: No such file or directory

That's line 21 of makefile.local trying to read in the depend file, which no longer gets built. That line sits outside the switch you turned off, so it still runs. Make grumbles and carries on — you can see it carried on, because it went straight to compiling. Not your problem right now. Worth mentioning to "an ordinary chessplayer" as a loose end, not something to chase.

The real news: this error is not new
0 was unexpected at this time.

Go back and look at your reply #13. That is the same error, word for word. At the time, "an ordinary chessplayer" guessed it was a quoting problem and suggested removing the quotes from the OSTYPE line. You did remove them — I can see it in your output, because the command now reads -DOSTYPE=\"Microsoft_...\" where it used to read -DOSTYPE=\""Microsoft_..."\".

So removing the quotes did not fix it. The error simply got hidden behind other errors that happened earlier in the build order. Now that we've cleared everything ahead of it, it's back.

That's the single most useful thing to report to the forum, because it corrects an assumption you've both been carrying for a week.

What the error is

It's the same family as the f was unexpected at this time you saw last time — it's cmd.exe's way of saying "I cannot parse this command line." Note that gcc never actually ran. cmd.exe gave up before starting it.

I'll be straight with you: I can't tell you which character it's choking on. The forum mangles the command line (you'll notice odd replacement characters scattered through it), so I can't inspect the real bytes. The prime suspect is the \" sequences in the OSTYPE argument, because a Unix shell treats backslash as an escape character and cmd.exe does not — but I'd be guessing, and I've already guessed once in this thread and been half wrong.

The cheap diagnostic worth running

Before anything else, do this. It takes two minutes and it will tell you something definite.

Open the command prompt and cd to your popeye-develop folder.
From your make output, select the entire long gcc ... line — the one starting gcc -W -Wall and ending -c pymain.c -o pymain.o — copy it, and paste it into the command prompt on its own. (To copy in the command prompt: drag-select the text, then press Enter. To paste: right-click.)
Press Enter.

If you get 0 was unexpected at this time. again, then the problem is entirely cmd.exe failing to parse that string, and we can bisect it by deleting pieces. If instead gcc runs and gives a normal compiler error, then the problem is in how make hands the command over, which is a different fix.

The recommendation I'd actually make now

Last time I said the Unix-shell route was worth keeping in reserve. It isn't in reserve any more. This is the second shell-parsing failure in a row, the first one was never really solved, and the makefiles will keep doing this. I'd stop fighting cmd.exe.

Here's the good part: you already have what you need. Back in reply #5 you listed what you installed — MinGW, Git, and Node. Git for Windows ships with a full Unix shell called Git Bash, plus real versions of touch, chmod, sed and the rest. It's been sitting on your machine this whole time.

Try this:

Open the Start menu, type Git Bash, and open it. You'll get a terminal window that looks a bit different from the command prompt.
Navigate to your folder. In Git Bash the path style is different — use forward slashes and /c/ instead of C:\:
   cd /c/Users/Name/Desktop/popeye-develop/popeye-develop
Run make. Try the plain version first:
   mingw32-make -f makefile.unx

If it says command not found, spell out the full path instead:

   /c/MinGW/bin/mingw32-make -f makefile.unx

Two notes. First, drop the DEPEND= this time. Inside a real Unix shell, the for loop recipe should work properly, so you don't need to switch it off. If that turns out to be wrong, you can always add it back. Second, make on Windows automatically uses a Unix shell when it finds one available, which is exactly what running inside Git Bash provides — that's the whole point of the exercise.

This costs you nothing and is completely reversible: if it makes things worse, close the window and you're back where you were. If it works, every remaining shell-syntax problem in the makefiles disappears at once.

One small thing for your forum post

Your reply #32 was clever — quoting the three explanations to show why my capitalization paragraph came out garbled. For what it's worth, chesspub's anti-caps filter turned that whole paragraph into nonsense, which is why it read as though I were comparing a thing to itself. Might be worth telling anyone reading that the filter is doing that, so they don't think the advice was incoherent.




I'm going to take a break for a few hours and then I will start doing what Claude says.
  
Back to top
 
IP Logged
 
Marc Benford
Full Member
***
Offline


I Love ChessPublishing!

Posts: 147
Joined: 07/17/13
Re: Chess problem solving softwares like Popeye
Reply #32 - yesterday at 19:16:31
Post Tools
Quote:
the correct way to stop a runaway command is Ctrl+C, not just any key.

Claude is right, Ctrl+C are exactly the two keys that I pressed at the same instant that the error message ended.

.

Quote:
The variable is DePeNd in all capitals in the real file. You've been re-typing capitals differently when you post — in reply #21 you showed these lines as ifdef DePeNd, and in reply #30 as ifdef DePeNd.


Quote:
Chesspub.com keeps saying "It appears that you are trying to write using ALL CAPS - Please be aware this is against forum rules."

Quote:
I transformed many uppercase letters into lowercase letters, so that the forum's anti-spam software would not prevent me from posting.

Quote:
Changing all-CAPS to alternating-CaPs. These stand out more as needing replacement back.


.

Okay so usually to run make I type
Code
Select All
mingw32-make -f makefile.unx

But this time, I typed
Code
Select All
mingw32-make -f makefile.unx DePeNd=

(On this forum, it's not possible to write in all caps. But, in the command prompt, I wrote the word DePeNd in all caps.)

And I got the following error message:
Code
Select All
mingw32-make CuRrPwD=./ -f ./makefile.local pymain.o
mingw32-make[1]: Entering directory 'C:/Users/Name/Desktop/popeye-develop/popeye-develop'
makefile.local:21: depend: No such file or directory
gcc -W -Wall -Wextra -Wpedantic -pedantic-errors -Warray-bounds=2 -Wcast-align -Wconversion -Wbad-function-cast -Wno-cast-qual -Wduplicated-cond -Wfloat-equal -Wformat=2 -Wformat-signedness -Wno-format-nonliteral -Wno-format-signedness -Winvalid-pch -Wlogical-op -Wmissing-declarations -Wredundant-decls -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wshift-negative-value -Wshift-overflow=2 -Wswitch -Wswitch-default -Wsync-nand -Wundef -Wunknown-pragmas -Wno-unused-parameter -Winit-self -Wwrite-strings -Wjump-misses-init   -O3 -flto  -DsIgNaLs -DmSg_In_MeM -DfXf -DnDeBuG -DfXf_MaX_aLiGnMeNt_TyPe=void* -DfXf_NoT_mUlTiPlE_aLiGnMeNt_TyPe=short -DsHaRiNg  -std=c99  -I. -DoStYpE=\"Microsoft_Windows-Version11-with_MinGW\" -DvErSiOn=4.101 -c pymain.c -o pymain.o
0 was unexpected at this time.
makefile.rules:16: recipe for target 'pymain.o' failed
mingw32-make[1]: *** [pymain.o] Error 255
mingw32-make[1]: Leaving directory 'C:/Users/Name/Desktop/popeye-develop/popeye-develop'
makefile.unx:350: recipe for target 'pymain.o' failed
mingw32-make: *** [pymain.o] Error 2
  
Back to top
 
IP Logged
 
Marc Benford
Full Member
***
Offline


I Love ChessPublishing!

Posts: 147
Joined: 07/17/13
Re: Chess problem solving softwares like Popeye
Reply #31 - yesterday at 18:48:41
Post Tools
Claude Opus 5 Max now says this:
Quote:
First, about my last answer

Installing chmod.exe was correct and necessary. Your chmod --version output proves it worked, and make did get past that line. You were always going to hit this next wall — chmod wasn't a detour, and skipping it wouldn't have saved you anything.

But I did get something wrong, and it matters. I told you to expect "more of the same" — more missing programs to copy across. That framing was wrong. What you're hitting now is a different kind of problem, and no amount of copying .exe files will fix it.

What the new error actually means

f was unexpected at this time. is a Windows message, produced by the command prompt itself (cmd.exe).

Now that we can see lines 55–66 — which is exactly why I asked you to post them — we can see what the recipe really does. After touch and chmod, it runs this:

for f in ./pygmarr.c; \
do \
...
done > depend

That is a loop written in the Unix shell language. Windows' command prompt has a for command too, but its syntax is completely different — it wants for %f in (...) do .... So cmd.exe reads for f in ..., finds the bare word f where it expected %f, and gives up.

The same recipe also uses backticks, $f, and pipes into sed. cmd.exe understands none of that either.

Here's the key distinction. touch and chmod were missing programs — you can install a missing program. This is missing shell syntax. The command prompt is not a Unix shell, and it cannot be turned into one by copying files into C:\MinGW\bin.

Why it repeats forever

depend is not an ordinary output file. It's a file that make generates and then reads back in as part of its own instructions — it's where make records which source file depends on which header file.

GnU make has a special behaviour for this: if a file it has read as part of the makefile turns out to be out of date, make rebuilds that file and then starts over from the very beginning so it can re-read the updated version. Normally that happens once. Here the rebuild never actually succeeds, so make rebuilds, restarts, rebuilds, restarts — forever.

By the way, the correct way to stop a runaway command is Ctrl+C, not just any key. That's what produced the Error 130 and Deleting file 'depend' at the end of your output — make cleaning up its half-built file after being interrupted.

What to try next: switch the whole thing off

Look at line 55 again:

ifdef DePeNd

That's a switch. Everything from there down to endif on line 66 only happens if the variable DePeNd has a value. The block at makefile.unx lines 339–344 is wrapped in the same switch.

And here's the good part: this whole mechanism is optional bookkeeping. It exists so that if you later edit a header file, make knows which .c files need recompiling. You're doing a one-shot build. You don't need it at all. Turning it off should skip the broken recipe entirely — and as a bonus, it should also make that output/latex/nesteddepend warning disappear, since that block sits inside the same switch.

You can turn it off without editing any file. Take whatever make command you normally run, and add DePeNd= on the end:

mingw32-make -f makefile.unx DePeNd=

Type it exactly like that, with nothing after the equals sign. In make, ifdef counts as false when a variable is set to an empty value, so this flips the switch off. Setting it on the command line also overrides whatever the makefiles themselves say, and it gets handed down to the sub-makes automatically.

One detail that will trip you up if you miss it

The variable is DePeNd in all capitals in the real file. You've been re-typing capitals differently when you post — in reply #21 you showed these lines as ifdef DePeNd, and in reply #30 as ifdef DePeNd. Open makefile.rules, look at line 55 with your own eyes, and use exactly what's there. If you type DePeNd= and the file says DePeNd, absolutely nothing will happen and it'll look like the advice failed.

If the command-line version doesn't work

A fallback that involves no # characters at all. Open makefile.rules and change line 55 from

ifdef DePeNd

to

ifdef DePeNdOfF

and make the same change to makefile.unx line 339. You're just renaming the switch to something that doesn't exist, which has the same effect as turning it off. One word changed, no comment characters, trivial to undo.

Also check whether a leftover depend file is sitting in your popeye-develop folder and delete it if so — it may hold garbage from the failed runs. Make said it deleted it, but confirm.

The bigger picture, honestly

You should know what you're up against. Popeye's makefiles assume a Unix shell. The command prompt isn't one. Every recipe that is just a plain gcc ... command works fine, and most of the compiling is exactly that — which is why you've gotten this far. But every recipe containing shell constructs will fail the way this one did.

There's a reasonable chance depend is the only shell-heavy recipe standing between you and a working popeye.exe, in which case switching it off finishes the job. But if you hit another "was unexpected at this time" error later on, the real fix isn't another workaround — it's running the build inside a genuine Unix-like shell on Windows, such as MSYS2 or the Git Bash shell that ships with Git for Windows. That's a bigger detour and I wouldn't take it until you know you need it. Worth mentioning to "an ordinary chessplayer" so you both have it in reserve.
  
Back to top
 
IP Logged
 
Marc Benford
Full Member
***
Offline


I Love ChessPublishing!

Posts: 147
Joined: 07/17/13
Re: Chess problem solving softwares like Popeye
Reply #30 - yesterday at 18:04:49
Post Tools
makefile.rules (lines 55-66)
Code
Select All
ifdef DePeNd
$(CuRrPwD)depend: $(SrC_cFiLeS:%=$(CuRrPwD)%) $(iNcLuDeS:%=$(CuRrPwD)%) $(CuRrPwD)makefile.local
	touch $@
	chmod u+w $@
	-for f in $(SrC_cFiLeS:%=$(CuRrPwD)%); \
	do \
		$(MaKeDePeNd) \
			-I. -Mg -Mt `echo $$f | sed -e "s/[.]c$$/$(ObJ_sUfFiX)/"` \
			$$f \
		| sed -e "s/[.]o:/\$$(ObJ_sUfFiX):/"; \
	done > $@
endif


.

So I moved chmod.exe to C:\MinGW\bin, like Claude told me to.

When I type chmod --version in the command prompt, I get the following message:
Code
Select All
chmod (GnU coreutils) 5.3.0
Written by David MacKenzie and Jim Meyering.

Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is No
warranty; not even for mErChAnTaBiLiTy or FiTnEsS fOr A pArTiCuLaR pUrPoSe.

So it worked.

.

But now when I run make, I get an error message that repeats endlessly!

This is the beginning of the error message:
Code
Select All
makefile.unx:342: target 'output/latex/nesteddepend' given more than once in the same rule.
mingw32-make CuRrPwD=./ -f ./makefile.local pymain.o


This is the part of the error message that keeps repeating forever:
Code
Select All
mingw32-make[1]: Entering directory 'C:/Users/Name/Desktop/popeye-develop/popeye-develop'
gcc -o gengmarr  -O3 -flto   gengmarr.o position/position-host.o position/board-host.o
gengmarr > pygmarr.c
touch depend
chmod u+w depend
for f in ./pygmarr.c; \
do \
        gcc -Mm -Mp -DsIgNaLs -DmSg_In_MeM -DfXf -DnDeBuG -DfXf_MaX_aLiGnMeNt_TyPe=void* -DfXf_NoT_mUlTiPlE_aLiGnMeNt_TyPe=short -DsHaRiNg  -std=c99  -DoStYpE=\"Microsoft_Windows-Version11-with_MinGW\" -DvErSiOn=4.101 \
                -I. -Mg -Mt `echo $f | sed -e "s/[.]c$/.o/"` \
                $f \
        | sed -e "s/[.]o:/\$(ObJ_SuFfIx):/"; \
done > depend
f was unexpected at this time.
makefile.rules:57: recipe for target 'depend' failed
mingw32-make[1]: [depend] Error 255 (ignored)
mingw32-make[1]: Leaving directory 'C:/Users/Name/Desktop/popeye-develop/popeye-develop'


This was the end of the error message:
Code
Select All
do \
        gcc -Mm -Mp -DsIgNaLs -DmSg_In_MeM -DfXf -DnDeBuG -DfXf_MaX_aLiGnMeNt_TyPe=void* -DfXf_NoT_mUlTiPlE_aLiGnMeNt_TyPe=short -DSmingw32-make[1]: *** Deleting file 'depend'
makefile.unx:350: recipe for target 'pymain.o' failed
mingw32-make: *** [pymain.o] Error 130


But I think that the error message only ended because I pressed a key on my keyboard, so this is probably not the true end of the error message. The error message would probably have kept repeating forever.

.

Claude's answer looked absolutely great. It looked far better than Google's AI mode's answers. But following Claude's instructions led to an endlessly repeating error message. So perhaps Claude's answer wasn't so great.

Also, Claude said "You could disable that line by putting a # at the very start of it". But last time I put a # in a makefile, it went horribly wrong. So I'm not doing that again.
  
Back to top
 
IP Logged
 
Page Index Toggle Pages: 1 [2] 3 4 
Topic Tools
‹ Previous Topic | Next Topic ›
Bookmarks: del.icio.us Digg Facebook Google Google+ Linked in reddit StumbleUpon Twitter Yahoo
 
  « Board Index ‹ Board Top  

ChessPub Forum » Powered by YaBB 2.6.12!
YaBB Forum Software © 2000-2026. All Rights Reserved.

Valid RSS Valid XHTML Valid CSS Powered by Perl Source Forge