(UTC)
  ChessPub Forum › Other › Chess and Computers › Chess problem solving softwares like Popeye
(Moderators: proustiskeen, Smyslov_Fan)
‹ Previous Topic | Next Topic ›
Page Index Toggle Pages: [1] 
Topic Tools
Very Hot Topic (More than 25 Replies) Chess problem solving softwares like Popeye (Read 4878 times)
an ordinary chessplayer
God Member
*****
Offline


I used to be not bad.

Posts: 1837
Location: Columbus, OH (USA)
Joined: 01/02/15
Re: Chess problem solving softwares like Popeye
Reply #59 - 08/02/26 at 22:45:59
Post Tools
Claude knows something I don't know. You have a genuine unix shell available. You should use it.

From reply #31 
Quote:
Claude wrote:
... 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.


I know something Claude doesn't know. The toolchain cross-i586-mingw32msvc has the code to fix these next errors you were getting when trying to build maxtime.o

From reply #42
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


From toolchains/cross-i586-mingw32msvc/make.incl (lines 47-50)
Code
Select All
# enumerate libraries to link
TaRgEtLiBs=-lwinmm
# winmm = Windows Multimedia Library (we use Multimedia Timers to
# implement option maxtime)

The same make.incl also defines the other symbols you have been messing with: ObJ_SuFfIx , ExE_PlAtFoRm_MaRk , ExE_SuFfIX , OsTyPe, PlAtFoRm.

You need to pay attention to the prerequisites.

From toolchains/cross-i586-mingw32msvc/make.incl (lines 7-17)
Code
Select All
# Requirements:
#
# The following tools can be used to produce executables for the
# target plarform and can be found in the $PATH:
# - i586-mingw32msvc-gcc
# - i586-mingw32msvc-ranlib
# - i586-mingw32msvc-strip

# The following tools can be used to produce executables for the host
# platform and can be found in the $PATH:
# - gcc

You have the fourth one, gcc, but do you have the others? The first place to check is your MinGW/bin folder for the files i586-mingw32msvc-gcc , i586-mingw32msvc-ranlib , i586-mingw32msvc-strip , possibly all three will have _slightly_ different names but you are looking for files ending with msvc-gcc , msvc-ranlib , msvc-strip , possibly followed by .exe . If you find those files but they begin with i386- instead, then there is a different toolchain for that, cross-i386-mingw32msvc , and you should use it instead of cross-i586-mingw32msvc as I am documenting here.

Let's assume you have all four requirements, and the first three are i586.

My recommendation is:
Edited:
Arg! I completely forgot you added some pieces. So before you delete your popeye-develop folder you need to copy those changes elsewhere. And then after downloading the master branch you need to copy those changes back.

Edited:
In a couple of places I made a typo ming32-make and now corrected that to mingw32-make

  1. Delete your popeye-develop folder and download the master branch from the popeye github repository
  2. Modify makefile.defaults (line 198) similar to Reply #12 but with this toolchain instead
         ToOlChAiN=cross-i586-mingw32msvc
  3. Modify toolchains/cross-i586-mingw32msvc/make.incl (lines 24-41) as given below
  4. Open the Git Bash shell as instructed in reply #33
    Caution: You may need to edit the PATH environment variable in git bash in order for it to find your MinGW bin folder. You will know that if mingw32-make does not run. Changing the path is simple and tricky at the same time.
  5. Within the Git Bash shell
        cd /your/popeye-master/
        mingw32-make -f makefile.unx
  6. Don't expect it to work without errors the first time.


Changes for toolchains/cross-i586-mingw32msvc/make.incl (lines 24-41). Only you will know the exact filenames you have to provide. Maybe you won't have to change them at all.
Code
Select All
# Now override where necessary

# Compiler selection
# ==================

# Compiler for creating executables on target
CcTaRgEt=whatever-name-you-found-for-msvc-gcc

# Linker for creating executables on target
LdTaRgEt=whatever-name-you-found-for-msvc-gcc

# Strip utility to remove unnecessary symbols from executable
StRiPTaRgEt=whatever-name-you-found-for-msvc-strip


# Archive index generator
# -----------------------
ArChIvE_InDeXeR=whatever-name-you-found-for-msvc-ranlib
« Last Edit: 08/03/26 at 04:32:11 by an ordinary chessplayer »  
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 #58 - 08/02/26 at 14:16:20
Post Tools


Claude Opus 5 Max says:

Quote:
Read what happened before the failure. This is the biggest step in the whole thread
-std=gnu99 is on every command line. The edit took.
tmpfile.c compiled. No error.
platform/windows32/library.lib.a was created — seven object files bundled into it: maxmem, maxtime, pytime, priority, beep, snprintf, tmpfile.
utilities and debugging compiled and bundled.
pygmarr compiled and bundled.
And then make ran this:
gcc -o py pymain.o solving/machinery/library.lib.a input/library.lib.a ... debugging/library.lib.a ./library.lib.a -O3 -flto

That is the final command of the entire build. Ninety-odd libraries, every one of them built, being stitched together into the program. There is nothing after it except stripping the result.

Popeye has fully compiled. What failed is the last step.

What that last step is

Three stages, and it's worth having the names straight:

Compiling turns each .c file into a .o file — machine code for that one file.
Archiving (ar) bundles a folder's .o files into one library.lib.a, with an index at the front saying which functions live inside.
Linking takes them all and matches every "call this function" to the actual function, producing the executable.

Stage 3 is where you are. The linker read pymain.o, found it calls check_hash_assumptions, alloc_pipe, dispatch and so on, went looking through ninety libraries, and reported that it couldn't find any of them.

The diagnosis: it's -flto

Notice how many symbols are undefined. Essentially every single function that main() calls, spread across a dozen different libraries. A genuine missing-code problem produces one or two undefined names. Producing all of them at once means the linker couldn't see inside the archives at all.

Here's why. -flto stands for link-time optimisation. It tells gcc: don't put finished machine code in the .o files — put an intermediate form instead, so that at the very end you can optimise across file boundaries all at once.

But then look at what your build runs:

ar rv platform/windows32/library.lib.a ...
ranlib platform/windows32/library.lib.a

Plain ar, plain ranlib. Those are ordinary tools that don't understand that intermediate form. When they build the index for each library, they find nothing to list, because the real function names are buried inside data they can't read. So the linker opens ninety libraries, sees ninety empty indexes, and concludes none of them contain anything it needs.

Modern gcc ships special versions called gcc-ar and gcc-ranlib that handle this. Popeye's Unix toolchain calls the plain ones, which is fine on systems where this is wired up automatically. Your MinGW is from an era before that was reliable.

The fix: drop -flto

You lose a modest amount of optimisation. -O3 on its own is still a fully optimised build — -flto is the extra squeeze on top. For a chess solver the practical difference is small, and a working program beats a marginally faster one that doesn't exist.

Step 1 — find where it's set. One command:

findstr /s /n /i "flto" makefile.* *.incl

If it points at toolchains\gcc\make.incl — which I expect, since that's where both previous settings lived — go straight ahead without waiting for me:

Open that file, find the line it names.
Delete just the  -flto from it. Leave -O3 and everything else exactly as it is.
Save.

If it points somewhere else, or the line looks unlike what you expect, stop and post it instead.

Step 2 — and don't skip this one

Every .o file currently on disk was built with -flto in it. Make considers them all up to date and will not rebuild them. If you just change the flag and re-run, make will skip straight to linking the same unreadable objects and fail in exactly the same way.

So you have to clear them out. make clean won't work — it uses rm, which Windows doesn't have. Do it by hand instead. From the popeye-develop folder, two separate commands:

Command A:

del /s *.o

Command B:

del /s *.lib.a

/s means "this folder and every folder inside it". If it asks Are you sure, answer Y. Nothing irreplaceable is being deleted — these are all generated files, and your source edits are untouched.

Step 3 — rebuild

Command C:

build

This one will be a full rebuild from scratch, not an eight-second top-up. Expect several minutes. Then, separately:

Command D:

findstr /n /i "error" output.txt
One thing to expect at the very end

Look at the link line again: gcc -o py. No .exe. But MinGW's gcc adds the extension by itself when you don't give one, so the file that lands on disk should be py.exe — even though make refers to the target as py.

That may cause a small hiccup on the final strip step, which is told to strip a file called py. If you see a complaint about that after the link succeeds, don't be alarmed: the program will already exist and work. Stripping only removes debugging padding to make the file smaller.

What to post
The output of findstr /s /n /i "flto" makefile.* *.incl, and whether you went ahead with the edit.
The output of Command D.
If Command D prints nothing at all, say so — and then check your popeye-develop folder for py.exe and tell me whether it's there and how big it is.


.

When Claude says to type "build" in the command prompt in step 3, he means to type this:
Code
Select All
mingw32-make -f makefile.unx DePeNd= pLaTfOrM=windows32 > output.txt 2>&1

I did not follow (and I do not intend to follow) his earlier suggestion of creating a file called build.bat

.

I will now take a break for a few hours.

@an ordinary chessplayer, if you read this, you can tell me whether or not Claude is leading me in the right direction. There's probably too many posts for you to read, but if you press Ctrl+F and type your username, you will see that Claude often talked to you directly at the end of his responses.
  
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 #57 - 08/02/26 at 13:34:34
Post Tools
Quote:
(Your paste dropped the final 9 — the real line ends in c99, since gcc would reject c9 outright.)

Yes, you are right. It's c99, not c9.

.

I changed c99 into gnu99 in toolchains\gcc\make.incl

.

When I ran command 1, the command prompt loaded for about 10 seconds.

The output of command 2 and the content of output.txt are too large, so I won't copy-paste them here on this forum, but I will provide them directly to Claude.
  
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 #56 - 08/02/26 at 13:22:13
Post Tools


Claude Opus 5 Max says:

Quote:
Understood on the one-line-versus-two — I'll label every command explicitly from now on.

What the search found
toolchains\gcc\make.incl:155:OTHER+=-std=c99

(Your paste dropped the final 9 — the real line ends in c99, since gcc would reject c9 outright.)

So the variable is called oThEr, and it lives in the same toolchain file that was setting pLaTfOrM=unix. Same file, same cause: a toolchain written for Unix, quietly imposing Unix assumptions.

Why the command-line trick is the wrong tool this time

Look carefully at the middle of that line:

oThEr+=-std=c99

That's +=, not =. In a makefile, += means add to what's already there rather than replace it. So oThEr is a collecting bucket — other lines elsewhere may well be dropping their own flags into it.

And here's the catch: when you set a variable on the command line, make treats your value as final and ignores every += in the makefiles for that variable. So oThEr=-std=gnu99 wouldn't just change the standard — it would empty the bucket of everything else that was supposed to go in it.

That's why this one needs an edit rather than an override. Same reasoning that made the command-line approach right for dEpEnD and pLaTfOrM makes it wrong here.

The edit
Open toolchains\gcc\make.incl in your text editor.
Go to line 155. It should read:
oThEr+=-std=c99
Change c99 to gnu99, so the line becomes:
oThEr+=-std=gnu99
Change nothing else. Don't touch the +=, don't add or remove spaces.
Save the file.

Two characters. And it's trivially reversible — if this causes new trouble, change gnu99 back to c99 and you're exactly where you are now.

Then run these — two separate commands

Command 1. Type this, press Enter, and wait for it to finish. Nothing will appear on screen; that's expected.

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

Command 2. Only after the first one has finished and you have your prompt back, type this and press Enter:

findstr /n /i "error" output.txt

Two commands, entered one after the other. Never on the same line.

What I expect

-std=gnu99 is the same C99 language with the extra non-standard functions left visible. MinGW's headers will stop hiding tempnam, and tmpfile.c should compile.

It should also head off the same problem in files further along — there are usually several places in a program that reach for a convenient non-standard function, and this uncovers all of them at once rather than one per round trip.

Whether that finishes platform/windows32 I can't promise. But that directory has six or seven files in it, you've cleared two error classes from it already, and it's the last one on the list before make starts linking.

What to post
The full output of Command 2 above.
If Command 2 prints nothing at all, say so explicitly — that would mean the build ran clean, and the next thing to check is whether py.exe has appeared in your popeye-develop folder.
If Command 2 prints a lot, also paste the last twenty or so lines of output.txt, since the error list alone doesn't always show which file make gave up on.
  
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 #55 - 08/02/26 at 13:13:05
Post Tools
Okay, let's go one step at a time.
When I run this
Code
Select All
findstr /s /n /i "c99" makefile.* *.incl

the command prompt prints this
Code
Select All
toolchains\gcc\make.incl:155:OTHER+=-std=c9


.

When you tell me to run something in the command prompt, if it's ambiguous whether it's one single line or two separate lines, tell me which is 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 #54 - 08/02/26 at 13:04:53
Post Tools


Claude Opus 5 Max says:

Quote:
Two process answers first

On telling you what to show me: fair, and I'll fix that. From now on I'll end with an explicit list of what to post. You shouldn't have to guess.

On the two commands: they are two separate commands, not one line. Type the first, press Enter, wait for it to finish, then type the second and press Enter.

Your first attempt proves it. You got:

mingw32-make: *** No rule to make target 'findstr'. Stop.

Run together on one line, cmd handled the > output.txt redirect and then passed everything after it — findstr /n /i "error" output.txt — to make as extra arguments. Make read findstr as the name of something to build, couldn't find a rule for it, and stopped. That's exactly the error you'd expect, and it's why output.txt held one line.

That's my fault for writing them in a single block without saying so.

The limits.h fix worked

maxtime.c is gone from the error list entirely. So is maxmem.c. The build now runs through the Windows platform files and stops at a different one:

platform/windows32/tmpfile.c:33:29: error: implicit declaration of function 'tempnam'

Note the run took eight seconds rather than a minute — because everything else was already compiled from before, and make only had this one directory left to do.

What the new error means

tempnam is a function for inventing a unique temporary-file name. MinGW does have it. Your compiler is not missing anything.

The problem is that it's hidden, and the thing hiding it is on your own command line:

-std=c99

-std=c99 means strict ISO C99, and nothing else. When gcc sees it, it quietly switches on a flag that tells the system headers "this program wants only standard C". MinGW's headers obey: they hide every function that isn't part of ISO C — and tempnam isn't. It's a Unix/POSIX function, so it gets locked away.

The second error, about making a pointer from an integer, is just the consequence: with no declaration in sight, gcc assumes the function returns a plain number, then finds that number being assigned to a text pointer.

One root cause, one fix.

The fix: gnu99 instead of c99

-std=gnu99 means the same C99 language plus the extras. It doesn't set the strict flag, so MinGW's headers stop hiding things. Nothing that compiled under c99 will fail under gnu99 — it only ever permits more.

This is worth doing at the variable level rather than by patching tmpfile.c, because there are almost certainly other files further along using other non-ISO functions, and this fixes the whole class at once.

Step 1 — find where it's set. Run this in the command prompt from your popeye-develop folder, and post exactly what it prints:

findstr /s /n /i "c99" makefile.* *.incl

That should show a variable holding -std=c99. Once we know its name, you can override it on the command line the same way you're already overriding the other two — no file editing.

For example, if the variable turns out to be called sTdC, the command would become:

mingw32-make -f makefile.unx DePeNd= pLaTfOrM=windows32 sTdC=-std=gnu99 > output.txt 2>&1

But don't guess at the name — wait for the findstr output.

Your question about switching compilers

No. Don't install anything right now.

Your compiler is not the problem and never has been. It compiled a large program's worth of source files without complaint. Everything that's gone wrong has been either Windows shell syntax or small portability gaps in Popeye's own code — a missing include, a hidden function. A different compiler would have hit the same gaps.

You're also close. You've gone from "nothing works" to "one directory left before linking" in a day.

For the longer view, though, here's the honest picture. The MinGW in c:\mingw is the old original project, largely unmaintained for over a decade, and 32-bit only. If you ever do want a modern setup, the thing to install is MSYS2, which provides a current 64-bit gcc under the mingw-w64 name.

And here's the part worth noticing: MSYS2 would also hand you a real Unix shell. That's the same thing that would dissolve the depend for loop, the if [ blocks, and the .enum.h rule — all at once. So your "second route" and "a better compiler" turn out to be the same download.

That's an argument for MSYS2 being your eventual route two. It is not an argument for abandoning route one when you're this close to the end of it.

What to post next
The output of findstr /s /n /i "c99" makefile.* *.incl

That's all I need for the next step. If you want to get ahead, you can also run the build again afterwards with whatever override that reveals, and post the output of findstr /n /i "error" output.txt — but the findstr above is the essential one.
  
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 #53 - 08/02/26 at 12:45:54
Post Tools
Claude, if you want me to show (copy-paste) you the content of the file output.txt, you should say so explicitly. I'm assuming that this is probably what you wanted me to show you, since you didn't tell me to show you anything else.

.

I added #include <limits.h> in platform/windows32/maxtime.c

Quote:
mingw32-make -f makefile.unx DePeNd= pLaTfOrM=windows32 > output.txt 2>&1
findstr /n /i "error" output.txt


I'm guessing this is supposed to be one single line, rather than two.

The first time I tried this (perhaps I made a mistake the first time), nothing got printed in the command prompt, and the file output.txt was extremely small. Here was the content of the file output.txt:
Code
Select All
mingw32-make: *** No rule to make target 'findstr'.  Stop.


The second time I tried this: The command prompt loaded for about 8 seconds. Nothing got printed in the command prompt. The file output.txt was very large. Here was the end of the file output.txt:
Code
Select All
4.101 -c platform/windows32/tmpfile.c -o platform/windows32/tmpfile.o
platform/windows32/tmpfile.c: In function 'platform_open_tmpfile':
platform/windows32/tmpfile.c:33:29: error: implicit declaration of function 'tempnam' [-Wimplicit-function-declaration]
   char const *result_name = tempnam(0,prefix);
                             ^~~~~~~
platform/windows32/tmpfile.c:33:3: warning: nested extern declaration of 'tempnam' [-Wnested-externs]
   char const *result_name = tempnam(0,prefix);
   ^~~~
platform/windows32/tmpfile.c:33:29: error: initialization makes pointer from integer without a cast [-Wint-conversion]
   char const *result_name = tempnam(0,prefix);
                             ^~~~~~~
makefile.rules:16: recipe for target 'platform/windows32/tmpfile.o' failed
mingw32-make[1]: *** [platform/windows32/tmpfile.o] Error 1
mingw32-make[1]: Leaving directory 'C:/Users/Name/Desktop/popeye-develop/popeye-develop'
makefile.unx:350: recipe for target 'platform/windows32/library.lib.a' failed
mingw32-make: *** [platform/windows32/library.lib.a] Error 2


.

Quote:
Your working command from now on
mingw32-make -f makefile.unx DePeNd= pLaTfOrM=windows32 > output.txt 2>&1


When I tried this, the result was the same as the second time above: "The command prompt loaded for about 8 seconds. Nothing got printed in the command prompt. The file output.txt was very large."
The end of the file output.txt was the same as above too.

.

Quote:
There is no toolchain in Popeye for native MinGW on Windows. Your exact combination — plain gcc, running on Windows, producing a Windows binary — isn't one of the supported configurations. That's not your fault and it isn't a bug; it's simply a gap.


So should I download and install an alternative to gcc/MinGW? If yes, which one do you recommend? Which one would work best with Popeye?
  
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 #52 - 08/02/26 at 11:53:19
Post Tools


Claude Opus 5 Max says:

Quote:
It worked, and the error count just collapsed

Look at what changed. Line 379 compiles platform/windows32/maxmem.c and there is no error underneath it — that file went through clean. Line 380 moves on to platform/windows32/maxtime.c, and there's exactly one error.

Previously: eight errors, all of them Unix-only signals and functions that Windows fundamentally doesn't have. Now: one error, and it's a completely different kind.

The pLaTfOrM=windows32 override did what it was supposed to. The build is now compiling the Windows code.

What the new error is
platform/windows32/maxtime.c:39:53: error: 'UiNt_MaX' undeclared here

UiNt_MaX is a standard C constant — the largest value an unsigned integer can hold. It's not a Windows thing or a Unix thing. It lives in a standard header called limits.h, and it's available to any C program that asks for that header.

The file forgot to ask.

This happens more often than you'd think. On many compilers limits.h gets pulled in indirectly, as a side effect of some other header the file already includes. So the omission sits there for years without anyone noticing, until someone compiles with a toolchain that doesn't drag it in. That's you, today.

Unlike the previous errors, nothing here is unavailable on your machine. The constant exists; the file just isn't reaching for it.

The fix — one line
Open platform/windows32/maxtime.c in your text editor.
Look at the top of the file. There'll be a handful of lines starting with #include.
Add this as a new line, immediately after the last of them:
#include <limits.h>
Start it at the very beginning of the line — no tab, no spaces in front. Unlike makefile recipes, C files don't care about tabs, but keeping it flush left matches the others.
Save, and run:
mingw32-make -f makefile.unx DePeNd= pLaTfOrM=windows32 > output.txt 2>&1
findstr /n /i "error" output.txt

This is your first edit to an actual C source file rather than a makefile. It's about as safe as an edit gets — adding an include can't break anything that was already working; at worst it does nothing.

Your search turned up something structural

This is the most interesting thing in your post, and it explains a great deal about the last three weeks:

toolchains\gcc\make.incl:188:      pLaTfOrM=unix

That's the file setting it, and here's the comment at the top of that same file:

Include file for makefile.unx for compiling on a Unix-ish platform (including MacOS X) for that same platform... I.e. host platform is equal to target platform.

So the toolchain you're using declares itself to be for building Unix programs on Unix machines. You're using it to build a Windows program on a Windows machine.

Now look at every toolchain in the tree that sets pLaTfOrM=windows32: MSVC6, MSVC8, MSVC12, C++BuilderX, and the three cross-... ones. The Microsoft ones need Visual Studio. The cross ones compile on Linux and target Windows.

There is no toolchain in Popeye for native MinGW on Windows. Your exact combination — plain gcc, running on Windows, producing a Windows binary — isn't one of the supported configurations. That's not your fault and it isn't a bug; it's simply a gap. And it's the root of the whole adventure: you picked the only toolchain that could plausibly work, and it quietly assumed Unix everywhere.

Worth flagging to "an ordinary chessplayer": look at toolchains/cross-i586-mingw32msvc/make.incl. It sets pLaTfOrM=windows32, ExE_pLaTfOrM_mArK=win32, and platform-specific file-name suffixes — several of the things Marc has been hand-patching one at a time. The only real difference from what he needs is that it calls a cross-compiler by name instead of plain gcc. Copying that file into a new toolchains/mingw/ folder and pointing its compiler variables at gcc might be a much cleaner base than patching the Unix toolchain.

That's a decision for him, and not something to do mid-flight. Finish the current run first.

Your working command from now on
mingw32-make -f makefile.unx DePeNd= pLaTfOrM=windows32 > output.txt 2>&1

Both overrides are needed every time, and neither touches a file. Keep them together.

What's ahead, from the lines you posted
py$(ExE_pLaTfOrM_mArK)$(ExE_sUfFiX): pymain$(ObJ_sUfFiX) $(OuRlIbS)
           $(LdTaRgEt)    $(ExEfIlE)$@ pymain$(ObJ_sUfFiX) ...
           $(StRiPtArGeT) $@

That's the final step, and it's two plain commands: link everything together, then strip the debugging information out. No shell loops, no if [, no backticks. Nothing there should trip on cmd.exe.

So the remaining road looks like: finish platform/windows32, build any libraries still outstanding, link, strip. The file that appears will be py.exe, since ExE_pLaTfOrM_mArK is empty in your setup.

And NeStEdLiBdIrS confirms the earlier reading — line 299's platform platform/$(pLaTfOrM) sits squarely inside the list of directories that actually get built and linked, which is exactly why the override took effect immediately.
  
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 #51 - 08/02/26 at 11:52:03
Post Tools
This time, I will only copy-paste one third of what I told Claude.

Quote:
mingw32-make -f makefile.unx DePeNd= pLaTfOrM=windows32 > output.txt 2>&1

Both variables are all capitals in reality. Then check the result the usual way:

findstr /n /i "error" output.txt


This prints the following in the command prompt:

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/windows32/maxmem.c -o platform/windows32/maxmem.o

380: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/windows32/maxtime.c -o platform/windows32/maxtime.o
381:platform/windows32/maxtime.c:39:53: error: 'UiNt_MaX' undeclared here (not in a function)
393:mingw32-make[1]: *** [platform/windows32/maxtime.o] Error 1
396:mingw32-make: *** [platform/windows32/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 #50 - 08/02/26 at 11:02:30
Post Tools


Claude Opus 5 Max says:

Quote:
There's the switch: line 299
299:      platform platform/$(pLaTfOrM) \

Singular pLaTfOrM, not the plural pLaTfOrMs inventory from line 196. One variable holding one directory name, and the build path is assembled from it. That's exactly why your very first search — for the literal string platform/unix — only ever found the catalogue: the build never writes that path out, it constructs it.

Your findstr on output.txt confirms the behaviour too. Only two platform directories were entered: platform and platform/unix. Not all five. So the selection mechanism is working exactly as designed — it's just selecting unix.

But it isn't set in either file we searched

Look at what your two searches returned. In makefile.unx, every line mentioning platform is: 5, 196, 197, 199, 299, 315, 320. Not one of them assigns a value to PLATFORM. In makefile.defaults: only a comment at 150 and ExE_pLaTfOrM_mArK at 154.

So pLaTfOrM gets its value in a file that makefile.* never matched.

The likely culprit is the toolchain include. Remember the error from reply #22, when Google AI had you set the toolchain to mingw:

makefile.unx:31: toolchains/mingw/make.incl: No such file or directory

Line 31 of makefile.unx pulls in toolchains/<whatever>/make.incl. That filename doesn't start with "makefile", so your searches never looked at it. And there's a toolchains/cross-i586-mingw32msvc folder — a Windows cross-compiling toolchain. My bet is that toolchains/gcc/make.incl sets pLaTfOrM=unix and the cross one sets a Windows value.

Try this immediately — no editing at all

Command-line variables override whatever the makefiles say. It worked for the depend switch; it should work here identically:

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

Both variables are all capitals in reality. Then check the result the usual way:

findstr /n /i "error" output.txt

If pLaTfOrM really is an ordinary variable, this bypasses whatever sets it to unix, and make will descend into platform/windows32 instead. Costs nothing, changes no files, and undoes itself the moment you leave it off the command line.

Two things to gather either way

Run the search that was missed:

findstr /s /n /i "platform" *.incl *.options makefile.local

Those are the file types your earlier pattern skipped. This should show you the line that sets it, and where.

Post makefile.unx lines 290 to 325. That covers the list line 299 belongs to, plus the rule that builds the final executable. Worth seeing both together.

A correction you'll want before you go hunting for the .exe

I told you to expect pywin64.exe. Look at lines 315 and 320:

315:all: py$(ExE_pLaTfOrM_mArK)$(ExE_sUfFiX)
320:py$(ExE_pLaTfOrM_mArK)$(ExE_sUfFiX): pymain$(OnJ_sUfFiX) $(oUrLiBs)

And makefile.defaults line 154 sets ExE_pLaTfOrM_mArK to nothing at all. With your ExE_sUfFiX=.exe, the file that appears will be py.exe, not pywin64.exe. The official release sets that mark to win64 to produce the published name; your build leaves it empty.

So when the build finishes, look for py.exe in the popeye-develop folder.

On heartbeat

It's not a user-facing feature, which is why it isn't in the manual. It sits in the platform layer next to timer.c and maxtime.c, which is where a program keeps the machinery for "what time is it" and "has my time limit expired". A heartbeat in that company is almost always an internal periodic tick — the mechanism that lets a long-running solve notice that something needs attention.

Nothing you'd ever type into an input file. If you want certainty rather than my inference, the file itself is short enough to open.

For "an ordinary chessplayer"

Found the selector: makefile.unx line 299 uses platform/$(pLaTfOrM) — singular, distinct from the pLaTfOrMs inventory on line 196. output.txt confirms only platform and platform/unix were entered, so the mechanism works and is simply choosing unix.

pLaTfOrM is assigned in neither makefile.unx nor makefile.defaults. Since makefile.unx line 31 includes toolchains/<toolchain>/make.incl, and that filename never matched the makefile.* search pattern, the toolchain include is the prime suspect — with toolchains/cross-i586-mingw32msvc presumably setting a Windows value instead.

Trying pLaTfOrM=windows32 on the command line as a no-edit test, since gcc -dumpmachine gives mingw32.
  
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 #49 - 08/02/26 at 10:45:08
Post Tools
Quote:
Look at what platform/makefile.local builds: maxmem, maxtime, beep, platform, timer, heartbeat. Those are memory limits, solving time limits, and the progress heartbeat.


What exactly is heartbeat? The word "heartbeat" doesn't appear in Popeye's manual: https://juliasfairies.com/wp-content/uploads/2012/07/py-engl.txt

.

.

Quote:
1. Which platform directories did make actually enter? This is the decisive one:

findstr /n /i "platform/" output.txt

If the only ones listed are platform and platform/unix, then something is selecting a single directory and it selected unix — and we need to find that something. If instead all five appear, then the list really is unfiltered and the problem is a different shape entirely. Either answer moves us forward.


Code
Select All
373:mingw32-make CuRrPwD=platform/ -f platform/makefile.local platform/library.lib.a
375:mingw32-make[1]: 'platform/library.lib.a' is up to date.
377:mingw32-make CuRrPwD=platform/unix/ -f platform/unix/makefile.local platform/unix/library.lib.a
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)
395:platform/unix/maxtime.c: In function 'platform_init':
396:platform/unix/maxtime.c:202:14: error: 'SiGaLrM' undeclared (first use in this function)
399:platform/unix/maxtime.c:202:14: note: each undeclared identifier is reported only once for each function it appears in
400:platform/unix/maxtime.c:202:14: error: passing argument 1 of 'signal' makes integer from pointer without a cast [-Wint-conversion]
401:In file included from ./platform/maxtime_impl.h:5:0,
402:                 from platform/unix/maxtime.c:1:
406:platform/unix/maxtime.c: In function 'platform_set_maxtime_timer':
407:platform/unix/maxtime.c:217:9: error: implicit declaration of function 'alarm' [-Wimplicit-function-declaration]
410:platform/unix/maxtime.c:217:9: warning: nested extern declaration of 'alarm' [-Wnested-externs]
412:platform/unix/maxtime.c:128:13: warning: 'ReDrawBoard' defined but not used [-Wunused-function]
415:makefile.rules:16: recipe for target 'platform/unix/maxtime.o' failed
416:mingw32-make[1]: *** [platform/unix/maxtime.o] Error 1
418:makefile.unx:350: recipe for target 'platform/unix/library.lib.a' failed
419:mingw32-make: *** [platform/unix/library.lib.a] Error 2


.

.

Quote:
2. Every mention of platform in the main makefile:

findstr /n /i "platform" makefile.unx


Code
Select All
5:# It is expected to work pretty portably on Unix-ish platforms with
196:pLaTfOrMs =     platform/other platform/windows32 platform/dos \
197:            platform/unix platform/windows64
199:nEsTeDsRcDiRs = . platform $(pLaTfOrMs) $(tOoLchAiNs) scripts \
299:    platform platform/$(pLaTfOrM) \
315:all:                py$(ExE_pLaTfOrM_mArK)$(ExE_sUfFiX)
320:py$(ExE_pLaTfOrM_mArK)$(ExE_sUfFiX): pymain$(ObJ_sUfFiX) $(oUrLiBs)


.

.

Quote:
3. And in the defaults file, where the earlier settings lived:

findstr /n /i "platform" makefile.defaults


Code
Select All
150:# Platform defaults
154:ExE_pLaTfOrM_mArK=
  
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 #48 - 08/02/26 at 10:26:59
Post Tools


Claude Opus 5 Max said:

Quote:
First, the easy answer: it's windows32, not windows64
gcc -dumpmachine
mingw32

That's the plain 32-bit MinGW. No x86_64 anywhere in it. So the Windows directory you want is platform/windows32, and the windows64 that happens to sit next to platform/unix on line 197 would have been the wrong choice.

This is exactly why that check was worth thirty seconds. Picking the name that was closest to hand would have swapped one set of compile errors for another.

Now the correction: line 197 is not the switch

I was wrong about what that line does, and seeing it in context makes it clear:

pLaTfOrMs = platform/other platform/windows32 platform/dos \
     platform/unix platform/windows64

nEsTeDsRcDiRs = . platform $(pLaTfOrMs) $(tOoLchAiNs) scripts \
     conditions conditions/amu ...

That isn't a choice between platforms. It's an inventory of all five, fed into a much bigger list of every directory in the project.

And look at what else is in that bigger list: scripts, and $(tOoLchAiNs). Neither of those contains C code that gets linked into Popeye. nEsTeDsRcDiRs is a housekeeping list — every directory the project owns, for purposes like building a source archive. It cannot be the list of things to compile and link.

So editing line 197 would be tinkering with a catalogue, not flipping a switch. Don't touch it.

Your platform/makefile.local rules out the other possibility too — it's just a list of C files and headers with no mention of subdirectories, so the platform folder isn't choosing its own sub-folder either.

Which means the real selection happens somewhere we haven't looked yet. That's the thing to find.

Three commands that should pin it down

1. Which platform directories did make actually enter? This is the decisive one:

findstr /n /i "platform/" output.txt

If the only ones listed are platform and platform/unix, then something is selecting a single directory and it selected unix — and we need to find that something. If instead all five appear, then the list really is unfiltered and the problem is a different shape entirely. Either answer moves us forward.

2. Every mention of platform in the main makefile:

findstr /n /i "platform" makefile.unx

3. And in the defaults file, where the earlier settings lived:

findstr /n /i "platform" makefile.defaults

Post all three. Somewhere in there I expect a variable holding a single directory name — something along the lines of a line setting a platform variable to unix, which then gets used as platform/$(that variable). Changing unix to windows32 on that one line would be the entire fix.

That would also explain why your earlier findstr found only one literal occurrence of "platform/unix": the build never writes that path out in full, it assembles it from a variable.

About the other fallback

You said you almost certainly don't need the optional features, and that's a fair read — but hold off for now.

Look at what platform/makefile.local builds: maxmem, maxtime, beep, platform, timer, heartbeat. Those are memory limits, solving time limits, and the progress heartbeat. Some of that is more central to using Popeye than "optional" suggests — a maximum solving time is genuinely useful when a problem turns out to be harder than expected.

More to the point: once we've found the selection variable, choosing windows32 costs exactly the same effort as choosing other. So there's no reason to settle for the cut-down version until we know the proper one doesn't work.

For "an ordinary chessplayer"

gcc -dumpmachine gives mingw32, so the target is platform/windows32.

Line 197 turns out to be the pLaTfOrMs inventory — all five directories — which feeds nEsTeDsRcDiRs alongside scripts and the toolchains. That's a housekeeping list, not the build list, so it's the wrong place to edit. platform/makefile.local names no subdirectories either.

So the question is: what mechanism turns that inventory into the single platform directory the build descends into, and where is it set? It never appears as a literal path, so it's presumably assembled from a variable.
  
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 #47 - 08/02/26 at 10:12:35
Post Tools
In the command prompt, when I type
Code
Select All
gcc -dumpmachine

it prints
Code
Select All
mingw32


.

.

This is the content of platform/makefile.local:
Code
Select All
# -*- Makefile -*-
#
SrC_cFiLeS = maxmem.c maxtime.c beep.c platform.c timer.c heartbeat.c
iNcLuDeS = maxmem.h maxtime.h maxtime_impl.h priority.h timer.h \
	beep.h beep_impl.h platform.h tmpfile.h heartbeat.h

include makefile.rules $(CuRrPwD)depend


.

.

Quote:
There's also a fallback if the Windows directory turns out to have troubles of its own: other is almost certainly a plain, feature-free implementation for platforms with no special support — no maximum-solving-time, no memory tricks. It would give you a working Popeye with a couple of optional features missing. Keep it in your back pocket, but don't reach for it yet.


Yes, I almost certainly don't need the optional features that are missing, so other is almost certainly good enough for me.

.

.

makefile.unx (lines 189-246)

Code
Select All
$(LatExZiPfiLe): $(tExFiLeS)
		zip -r $@ $^

.iNtErMeDiAtE: $(LaTeXtArFiLe)

LaTeXdist: $(LaTeXgZiPfiLe) $(LaTeXcOmPrEsSfiLe) $(LaTeXziPfiLe)

pLaTfOrMs =     platform/other platform/windows32 platform/dos \
		platform/unix platform/windows64

nEsTeDsRcDiRs = . platform $(pLaTfOrMs) $(tOoLchAiNs) scripts \
    conditions conditions/amu conditions/ultraschachzwang conditions/marscirce \
    conditions/circe conditions/anticirce \
    conditions/owu conditions/maff conditions/singlebox conditions/einstein \
    conditions/transmuting_kings conditions/koeko \
    optimisations DhT \
    stipulation stipulation/boolean \
    stipulation/battle_play stipulation/help_play \
    stipulation/goals \
    stipulation/goals/mate \
    stipulation/goals/stalemate stipulation/goals/doublestalemate \
    stipulation/goals/autostalemate stipulation/goals/automate stipulation/goals/any \
    stipulation/goals/circuit stipulation/goals/circuit_by_rebirth \
    stipulation/goals/exchange stipulation/goals/exchange_by_rebirth \
    stipulation/goals/target stipulation/goals/check \
    stipulation/goals/doublemate stipulation/goals/countermate \
    stipulation/goals/capture stipulation/goals/steingewinn \
    stipulation/goals/enpassant stipulation/goals/castling \
    stipulation/goals/proofgame stipulation/goals/atob \
    stipulation/goals/chess81 stipulation/goals/kiss \
    stipulation/goals/king_capture \
    stipulation/goals/immobile stipulation/goals/notcheck \
    solving solving/battle_play solving/help_play solving/boolean solving/machinery solving/goals \
    retro \
    position position/effects \
    pieces pieces/walks pieces/walks/pawns pieces/walks/angle \
    pieces/walks/chinese pieces/walks/argentinian \
    pieces/attributes pieces/attributes/neutral \
    pieces/attributes/paralysing pieces/attributes/kamikaze \
    pieces/attributes/total_invisible \
    optimisations/orthodox_mating_moves \
    optimisations/intelligent \
    optimisations/intelligent/mate optimisations/intelligent/stalemate \
    optimisations/goals \
    optimisations/goals/castling optimisations/goals/enpassant \
    optimisations/goals/chess81 optimisations/goals/capture \
    optimisations/goals/target \
    optimisations/killer_move optimisations/count_nr_opponent_moves \
    optimisations/ohneschach \
    options options/no_short_variations \
    options/maxsolutions \
    options/stoponshortsolutions \
    options/movenumbers \
    input input/plaintext input/plaintext/geometry \
    output \
    output/latex output/latex/tree output/latex/line \
    output/plaintext output/plaintext/tree output/plaintext/line \
    utilities debugging
  
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 #46 - 08/02/26 at 09:55:42
Post Tools


Claude Opus 5 Max says:

Quote:
That's the answer, in two lines

The platform folders are dos, other, unix, windows32, windows64. So Popeye absolutely does ship Windows implementations. You've been compiling the Unix one on Windows 11.

And your findstr result is beautifully specific:

makefile.unx:197: platform/unix platform/windows64

One hit, in one file, on one line — and that line names the Unix directory and a Windows directory side by side. Line 197 of makefile.unx is where the choice is made. That's the whole hunt over in a single command.

Three quick things before touching it

1. Post makefile.unx lines 190 to 205. We need to see which variable line 197 belongs to and how the list is punctuated. Lists like this usually run across several lines with backslashes at the ends, and deleting the wrong piece of a continued line breaks it in a way that's annoying to diagnose. One look and the edit becomes obvious and safe.

2. Find out whether your gcc is 32-bit or 64-bit. This decides between windows32 and windows64. In the command prompt:

gcc -dumpmachine

It prints one short line. Something containing x86_64 means 64-bit; a plain mingw32 means 32-bit. This genuinely matters — your compiler lives in c:\mingw, which is where the older 32-bit MinGW installs itself, so I would not assume windows64 is right for you just because that's the name that happens to be on line 197.

3. Post the contents of platform/makefile.local. It should be short. Directories in this build often carry their own list of sub-directories to descend into, and if that file names unix without the platform/ prefix, your findstr wouldn't have caught it and there's a second place that needs changing.

What the edit will almost certainly be

Remove platform/unix from line 197, leaving the Windows directory that matches your compiler. That stops make ever entering platform/unix, so maxtime.c and its siblings never get compiled, and the Windows equivalents get built instead.

There's a second reason to do it this way. If that line really does build both directories, you'd hit a fresh problem later at link time: two directories each supplying a platform_init, and the linker objecting to duplicate definitions. Dropping one fixes the error you have and prevents one you haven't met yet.

Perspective

Nothing is broken here. This isn't a bug, it's a configuration choice — the build was told to use the Unix platform layer and did exactly that. Popeye's own Windows release, pywin64.exe, is built from these same sources with a Windows directory selected instead.

There's also a fallback if the Windows directory turns out to have troubles of its own: other is almost certainly a plain, feature-free implementation for platforms with no special support — no maximum-solving-time, no memory tricks. It would give you a working Popeye with a couple of optional features missing. Keep it in your back pocket, but don't reach for it yet.

For "an ordinary chessplayer"

platform contains dos, other, unix, windows32 and windows64. makefile.unx line 197 names platform/unix and platform/windows64 together, and it is the only reference to platform/unix in any makefile in the tree. The build descends into platform/unix on Windows 11, which is where the SIGHUP / SIGALRM / alarm errors against MinGW's signal.h come from.

The question for him: what's the cleanest way to drop platform/unix from that list, and is windows32 or windows64 the right partner given the compiler installed in c:\mingw?
  
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 #45 - 08/02/26 at 09:44:41
Post Tools
Quote:
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.


The subfolders are:
dos
other
unix
windows32
windows64

.

Quote:
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.


It prints the following:
Code
Select All
makefile.unx:197:               platform/unix platform/windows64
  
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 #44 - 08/02/26 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 - 08/02/26 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 - 08/02/26 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 - 08/02/26 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 - 08/02/26 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 - 08/02/26 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 - 08/02/26 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 - 08/02/26 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 - 08/02/26 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 - 08/02/26 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: 1837
Location: Columbus, OH (USA)
Joined: 01/02/15
Re: Chess problem solving softwares like Popeye
Reply #34 - 08/01/26 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 - 08/01/26 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 - 08/01/26 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 - 08/01/26 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 - 08/01/26 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
 
Marc Benford
Full Member
***
Offline


I Love ChessPublishing!

Posts: 147
Joined: 07/17/13
Re: Chess problem solving softwares like Popeye
Reply #29 - 08/01/26 at 17:59:54
Post Tools
I asked Claude Opus 5 Max to read this thread and to tell me what to do next. Here is his answer:

Quote:
I've read the thread. Good news first: the DLL fix worked, and you made real progress.

What just happened

Look carefully at the two error messages. Before, touch depend failed. Now touch depend runs silently — which means it succeeded — and the build moves on to the next line, chmod u+w depend, which is the one that now fails.

There's another confirmation hiding in the numbers. Your previous run ended with Error -1073741515. That ugly number is actually Windows' code for "a required DLL could not be found" — exactly matching the popup you saw. This time you're back to plain Error 2, "the system cannot find the file specified," which is Windows' code for "the program itself doesn't exist." Different problem, one step further along.

What's wrong now

The recipe in makefile.rules doesn't just run touch. It runs two commands in a row:

touch depend
chmod u+w depend

chmod is another Unix utility that Windows doesn't have. Same situation as touch, and the same fix.

What to do

chmod.exe is in the same coreutils-5.3.0-bin.zip you already downloaded — the 5.2 MB one, not the dep one. You don't need any new download.

Open the folder where you unzipped coreutils-5.3.0-bin.zip (the same folder you got touch.exe from).
Go into the bin subfolder.
Find chmod.exe — it'll be near the top, alphabetically just after chgrp.exe.
Copy it into C:\MinGW\bin, right alongside touch.exe.
Optional sanity check: open a command prompt and type chmod --version. You should get version and copyright info. If instead you get "not recognized," something went wrong with the copy.
Run make again.

You shouldn't get a popup this time — chmod.exe needs the same two DLLs as touch.exe, and those are already sitting in C:\MinGW\bin.

A warning worth taking seriously

You're going to hit more of these. The Popeye makefiles were written for Unix, and MinGW ships almost none of these small utilities. Expect to repeat this cycle a few more times.

The pattern to recognize is this line:

process_begin: CreateProcess(NULL, chmod u+w depend, ...) failed.

The word right after NULL, is the missing program. Find <that name>.exe in the coreutils bin folder, copy it to C:\MinGW\bin, run make again.

But do this one file at a time. Do not copy the whole bin folder into C:\MinGW\bin. This is the caution "an ordinary chessplayer" gave you and it's a real one. Several coreutils programs have the same names as Windows commands, and if Windows finds the Unix version first, things break in confusing and occasionally serious ways. Names to be careful about include date, dir, echo, sort, mkdir, rmdir, link, install, expand, and whoami. chmod is safe — Windows genuinely has no chmod.

Also worth reporting to the forum

When you post, it would help "an ordinary chessplayer" if you paste in what makefile.rules actually says around lines 55–60, rather than just 55–57. You showed lines 55–57 last time, which ended at touch $@ — but we now know there's a chmod u+w $@ on the next line. Seeing the whole recipe lets him tell you whether more commands are queued up after that.

One alternative he might suggest, so you're not surprised by it: the chmod line is arguably pointless here, since touch just created that file and a freshly created file is already writable. You could disable that line by putting a # at the very start of it. I'd install chmod.exe instead — it's less invasive, and you'll probably want chmod available later anyway. But mention that you know the option exists.
  
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 #28 - 08/01/26 at 17:58:43
Post Tools
Okay, I did this, and now when I run make I get this 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
process_begin: CreateProcess(NuLl, chmod u+w depend, ...) failed.
make (e=2): The system cannot find the file specified.
makefile.rules:57: recipe for target 'depend' failed
mingw32-make[1]: *** [depend] Error 2
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


It's the same as the previous error message, except that this
Code
Select All
touch depend
process_begin: CreateProcess(NULL, touch depend, ...) failed.

has turned to this
Code
Select All
touch depend
chmod u+w depend
process_begin: CreateProcess(NULL, chmod u+w depend, ...) failed.
  
Back to top
 
IP Logged
 
an ordinary chessplayer
God Member
*****
Offline


I used to be not bad.

Posts: 1837
Location: Columbus, OH (USA)
Joined: 01/02/15
Re: Chess problem solving softwares like Popeye
Reply #27 - 08/01/26 at 14:45:57
Post Tools
Marc Benford wrote on 08/01/26 at 06:04:37:
Quote:
touch.exe - System error

Impossible to execute the code, because libintl3.dll cannot be found. Reinstalling the program could correct this problem.

(This is a translation of what the popup says, because my computer is not in English.)

For once Windows gives a helpful error message.

It was my mistake. I knew about the dependencies, but way back in the day not all gnu utilities were internationalized, and I wrongly guessed touch would not need the dll.
  • Go to sourceforge and download coreutils-5.3.0-dep.zip
  • Extract libiconv2.dll and libintl3.dll from the bin folder and move them to your MinGW path (same folder where you placed touch.exe).
  
Back to top
 
IP Logged
 
an ordinary chessplayer
God Member
*****
Offline


I used to be not bad.

Posts: 1837
Location: Columbus, OH (USA)
Joined: 01/02/15
Re: Chess problem solving softwares like Popeye
Reply #26 - 08/01/26 at 14:05:41
Post Tools
I couldn't attach touch.txt last night because of a resource limit. Here it is:

@echo off
REM quick and dirty fake touch
REM WARNING does not handle options, multiple files, etc.
if not ".." == ".%1." (
  if exist %1 ( copy /b %1 +,, >NUL ) else ( type NUL > %1 )
)
  
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 #25 - 08/01/26 at 06:04:37
Post Tools
I just recently stumbled upon Google's AI mode by accident. It was the first time that I used an LLM. And I remembered what Dink Heckler said. But I now realize that Google's AI mode is not a very good LLM. There are much better LLMs. So henceforth, I will use Gemini 3.1 Pro Extended.

.

Quote:
You can check whether touch exists in your path. From the Windows command prompt run the following command:
    touch --version
Output that contains "not recognized as an internal or external command" means you don't have touch;


It says:
Code
Select All
'touch' is not recognized as an internal or external command, operable program or batch file.

So indeed, I don't have touch.

.

Okay, I installed touch by following your method (A). I downloaded coreutils-5.3.0-bin.zip, I unzipped it, I clicked on bin, I saw touch.exe, and I moved touch.exe to C:\MinGW\bin

Then, I ran make again.

On my command prompt, I get 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
makefile.rules:57: recipe for target 'depend' failed
mingw32-make[1]: *** [depend] Error -1073741515
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


The error message that is written in the command prompt is almost the same as last time. There are only two differences.

The first difference is that this line has disappeared:
Code
Select All
process_begin: CreateProcess(NULL, touch depend, ...) failed.
make (e=2): The system cannot find the file specified.


The second difference is that this line
Code
Select All
mingw32-make[1]: *** [depend] Error 2

has changed into this line
Code
Select All
mingw32-make[1]: *** [depend] Error -1073741515

(the number has changed)

But the most important difference is not in the command prompt. The most important difference is that, this time, when I run make, I get a popup on my screen that says:
Quote:
touch.exe - System error

Impossible to execute the code, because libintl3.dll cannot be found. Reinstalling the program could correct this problem.

(This is a translation of what the popup says, because my computer is not in English.)
  
Back to top
 
IP Logged
 
an ordinary chessplayer
God Member
*****
Offline


I used to be not bad.

Posts: 1837
Location: Columbus, OH (USA)
Joined: 01/02/15
Re: Chess problem solving softwares like Popeye
Reply #24 - 08/01/26 at 04:44:30
Post Tools
Recommendation: You could try changing the makefile in some way, but probably would not work unless we know why touch was needed.

The better option is to install touch. I offer two simple methods, but there are others. Both A and B rely on the Windows behavior that running touch will also try to run touch.exe and touch.bat .

(A) You can get a unix touch.exe compiled for Windows from the gnuwin32 collection.
https://gnuwin32.sourceforge.net/packages/coreutils.htm

Caution: You need to put any of these in your path in such a way that unix utilities don't interfere with Windows utilities. For example there is a windows date command and a unix date command, and you can seriously break Windows if it finds the unix date command instead of the needed Windows date command. That's just one example I know about. But you should be safe with touch, since Windows doesn't have it.
  • Go to sourceforge and download coreutils-5.3.0-bin.zip
  • Extract touch.exe from the bin folder and move it to your MinGW path.

(B) You can get touch.bat from the attachment.

Caution: As I wrote it touch.bat is not very good. But there is only one invocation of touch in your makefiles, and touch.bat does work for that one.
  • Download the touch.txt attachment
  • Rename touch.txt to touch.bat and move it to your MinGW path.

After you finish with either A or B, run make again.
  
touch.txt ( 0 KB | 29 Downloads )
Back to top
 
IP Logged
 
an ordinary chessplayer
God Member
*****
Offline


I used to be not bad.

Posts: 1837
Location: Columbus, OH (USA)
Joined: 01/02/15
Re: Chess problem solving softwares like Popeye
Reply #23 - 08/01/26 at 03:26:14
Post Tools
Once again I split this into two posts. First one is diagnosis, second one is recommendation. 


Marc Benford wrote on 07/30/26 at 03:59:01:

Quote:
Goggle AI wrote:
The reason your build failed is because the makefile.unx file is written for Unix-like environments (Linux/macOS), and Windows command prompt natively lacks the touch utility. When mingw32-make tries to execute touch depend, Windows throws the error:
make (e=2): The system cannot find the file specified.

This is probably correct. 

Recall that we had a similar problem with OsTyPe because it relied on the output of uname, another unix utility.

But, since I don't have MinGW installed, I don't know what unix commands it bundles. I am flying a little blind there and can only react to these errors as you report them.

You can check whether touch exists in your path. From the Windows command prompt run the following command:
    touch --version
Output that contains "not recognized as an internal or external command" means you don't have touch; output that contains version number, copyright, license, and author information means you do have touch. Obviously your fix for the touch error is different depending on which case is true.

But again, I think Google AI is probably correct that you don't have touch.

Marc Benford wrote on 07/30/26 at 03:59:01:

Quote:
Goggle AI wrote:
Because you are using standard Windows command prompt, you can easily bypass this by telling the compilation tool to use the Windows-native file creation command instead of Unix's touch.

Follow these steps to successfully compile Popeye.

1. Fix the touch Error Natively

You do not need to install anything new. You just need to pass an extra variable to your make command so it translates touch into a Windows native command.

Run this exact command in your prompt:

cmdmingw32-make -f makefile.unx ToUcH="type nul >"

This is most definitely wrong. You are being advised to overwrite the file "depend" with an empty file of the same name, but touch only creates an empty file if the file does not already exist. And it wouldn't work anyway, since the makefile recipe is running touch and ignoring ${ToUcH}, as you found when you tried make again.

You have a couple of options for fixing touch. See the recommendation post.


Marc Benford wrote on 07/30/26 at 03:59:01:

Quote:
Goggle AI wrote:
2. If you see a gengmarr execute error

If the compiler throws an error right after that saying gengmarr is not recognized, it means Windows is trying to run a newly generated local program without explicitly knowing it is in the current directory. If that happens, force it to look locally by running:

cmdmingw32-make -f makefile.unx ToUcH="type nul >" CuRrPwD=./

Also wrong. CuRrPwD is already correctly being set to ./ which you can see from the make message "entering directory .../popeye-develop".


Marc Benford wrote on 07/30/26 at 03:59:01:

Quote:
Goggle AI wrote:
you must tell the build system to stop using Unix commands and use Windows native settings.

Not true. Would be true if you were using a Windows compiler. But you are using MinGW as a fake unix environment. gcc under MinGW should use unix commands.


Marc Benford wrote on 07/30/26 at 03:59:01:

Quote:
Goggle AI wrote:
(1) mingw32-make -f makefile.unx ToOlChAiN=mingw
(2) mingw32-make -f makefile.unx clean
(3a) mingw32-make -f makefile.w32
(3b) mingw32-make -f makefile.gcc

Weird. 

(1) Your options for ToOlChAiN are limited to the directory names in the .../popeye-develop/toolchain folder. "mingw" is not one of the folders. There is a directory "cross-i586-mingw32msvc" which you could try as a value for toolchain. It also uses unix commands so will not fix your touch problem. Probably best to stick with the gcc toolchain.

(2) "clean" is a standard make target telling it to undo some of the changes from previous runs of make. You can find it on line 364 of makefile.unx. It's not a bad idea to run make clean, but again it won't fix your issue.

(3a) and (3b) These makefiles don't even exist, Google AI is just making stuff up.

So in practice Google AI is leading you away from the solution rather than towards 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 #22 - 07/30/26 at 03:59:01
Post Tools
I tried asking Google's AI mode.

.

The first time it said this:

Quote:
The reason your build failed is because the makefile.unx file is written for Unix-like environments (Linux/macOS), and Windows command prompt natively lacks the touch utility. When mingw32-make tries to execute touch depend, Windows throws the error:
make (e=2): The system cannot find the file specified.

Because you are using standard Windows command prompt, you can easily bypass this by telling the compilation tool to use the Windows-native file creation command instead of Unix's touch.

Follow these steps to successfully compile Popeye.



1. Fix the touch Error Natively

You do not need to install anything new. You just need to pass an extra variable to your make command so it translates touch into a Windows native command.

Run this exact command in your prompt:

cmdmingw32-make -f makefile.unx ToUcH="type nul >"



2. If you see a gengmarr execute error

If the compiler throws an error right after that saying gengmarr is not recognized, it means Windows is trying to run a newly generated local program without explicitly knowing it is in the current directory. If that happens, force it to look locally by running:

cmdmingw32-make -f makefile.unx ToUcH="type nul >" CuRrPwD=./



Why this happens and what to expect

makefile.unx is structurally built for Unix systems. By declaring ToUcH="type nul >", you are tricking the makefile into using a standard Windows blank file creator instead of the Linux touch utility.


I tried running the two commands that it wanted me to run, but it didn't work, the error message stayed exactly the same.

.

The second time it said this:

Quote:
The error you are seeing (touch depend failed) happens because the Unix-style makefile (makefile.unx) expects Linux command-line utilities (like touch) which do not exist natively on Windows Command Prompt.

[...]

you must tell the build system to stop using Unix commands and use Windows native settings.

[...]

Run this exact command instead:

cmdmingw32-make -f makefile.unx ToOlChAiN=mingw

(Adding ToOlChAiN=mingw instructs the configuration file to skip Linux-specific rules like touch depend and handle the build correctly on Windows).


After I ran the command that it told me to run, I got the following error message:

Code
Select All
makefile.unx:31: toolchains/mingw/make.incl: No such file or directory
mingw32-make: Circular FoRcE <- FoRcE dependency dropped.
mingw32-make CuRrPwD=./ -f ./makefile.local FoRcE
mingw32-make[1]: Entering directory 'C:/Users/Name/Desktop/popeye-develop/popeye-develop'
mingw32-make[1]: Nothing to be done for 'FoRcE'.
mingw32-make[1]: Leaving directory 'C:/Users/Name/Desktop/popeye-develop/popeye-develop'
mingw32-make CuRrPwD=./ -f ./makefile.local makefile.options
mingw32-make[1]: Entering directory 'C:/Users/Name/Desktop/popeye-develop/popeye-develop'
mingw32-make[1]: Nothing to be done for 'makefile.options'.
mingw32-make[1]: Leaving directory 'C:/Users/Name/Desktop/popeye-develop/popeye-develop'
mingw32-make CuRrPwD=toolchains/mingw/ -f toolchains/mingw/makefile.local toolchains/mingw/make.incl
mingw32-make[1]: Entering directory 'C:/Users/Name/Desktop/popeye-develop/popeye-develop'
mingw32-make[1]: toolchains/mingw/makefile.local: No such file or directory
mingw32-make[1]: *** No rule to make target 'toolchains/mingw/makefile.local'.  Stop.
mingw32-make[1]: Leaving directory 'C:/Users/Name/Desktop/popeye-develop/popeye-develop'
makefile.unx:350: recipe for target 'toolchains/mingw/make.incl' failed
mingw32-make: *** [toolchains/mingw/make.incl] Error 2


.

The third time it suggested typing this
Code
Select All
mingw32-make -f makefile.unx clean

and then either this
Code
Select All
mingw32-make -f makefile.w32

or this
Code
Select All
mingw32-make -f makefile.gcc

But I won't do this unless you tell me to. I'm afraid this might delete the file makefile.unx.
  
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 #21 - 07/30/26 at 03:57:22
Post Tools
Quote:
Actually $(eXeCuTe) is blank, which is what we wanted. It was not what was causing the error message about '.', but it was worth checking. I will let you work out for yourself why "11" was echoed when $(eXeCuTe) is blank.


I get it. echo is the print function of makefiles. echo "1$(eXeCuTe)1" prints a 1 and then prints whatever is the output of eXeCuTe and then prints another 1. It sandwiches the output of eXeCuTe between two 1s. You added the two 1s so that when you see two 1s in the error message you would know that what's in between the two 1s is the output of eXeCuTe.

.

Okay, I made the modifications and then I ran make, and here is the error message that I get now:

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
process_begin: CreateProcess(NULL, touch depend, ...) failed.
make (e=2): The system cannot find the file specified.
makefile.rules:57: recipe for target 'depend' failed
mingw32-make[1]: *** [depend] Error 2
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


Everything up to gengmarr > pygmarr.c is the same. It's what's after that has changed.

makefile.rules (lines 55-57)
Code
Select All
ifdef DEPEND
$(CURRPWD)depend: $(SRC_CFILES:%=$(CURRPWD)%) $(INCLUDES:%=$(CURRPWD)%) $(CURRPWD)makefile.local
	touch $@
  
Back to top
 
IP Logged
 
an ordinary chessplayer
God Member
*****
Offline


I used to be not bad.

Posts: 1837
Location: Columbus, OH (USA)
Joined: 01/02/15
Re: Chess problem solving softwares like Popeye
Reply #20 - 07/29/26 at 19:50:57
Post Tools
Recommended changes. Line numbers are from the github files, if you added or deleted lines then they may be slightly different for you.

makefile.defaults (lines 156-157)
Code
Select All
# suffix for executables
ExE_sUfFiX=

change to
Code
Select All
# suffix for executables
ExE_sUfFiX=.exe


makefile.local (lines 67-68)
Code
Select All
pygmarr.c: ./gengmarr$(ExE_sUfFiX)
	$(ExEcUtE) ./gengmarr$(ExE_sUfFiX) > $@

change to
Code
Select All
pygmarr.c: gengmarr$(ExE_sUfFiX)
	$(ExEcUtE) gengmarr$(ExE_sUfFiX) > $@

Then try make again.
  
Back to top
 
IP Logged
 
an ordinary chessplayer
God Member
*****
Offline


I used to be not bad.

Posts: 1837
Location: Columbus, OH (USA)
Joined: 01/02/15
Re: Chess problem solving softwares like Popeye
Reply #19 - 07/29/26 at 19:33:26
Post Tools
Responding in 2 separate posts. First one will annotate the messages you got. Second one will give my recommendations.

Marc Benford wrote on 07/25/26 at 19:33:39:
When I first type
Code
Select All
cd C:\Users\Name\Desktop\popeye-develop\popeye-develop

and then I type
Code
Select All
gcc -o gengmarr  -O3 -flto   gengmarr.o position/position-host.o position/board-host.o

it doesn't do anything, the command prompt doesn't return any message at all.

This is expected behavior. If the gcc command succeeds, it does not print any message.


Marc Benford wrote on 07/25/26 at 19:33:39:

In the popeye-develop folder, I see a file called pygmarr.c, and I see three gengmarr files:
- gengmarr.c
- gengmarr.exe
- gengmarr.o

.

Quote:
Try running gengmarr from the command prompt, without redirection, and you should get back some C code in the command prompt.
Simply
    ./gengmarr


I'm not sure what to do there.

When I type
Code
Select All
./gengmarr

in the command prompt, I get the following error message:
Code
Select All
'.' is not recognized as an internal or external command,
operable program or batch file.

makefile.local is problematic on lines 67-68. Unix uses "/" as the path separator, whereas historically Windows uses "\", while modern Windows sometimes understands "/". Here I give a Windows session that shows the problem. First thing to notice is that the cd command succeeds even though I used the "wrong" path separator. Second thing to notice is that the first error message about '.' is totally confusing. Third thing to notice is that the message about '.' is the same error message you received from make.

Code
Select All
C:\Users\aoc>cd ../Public

C:\Users\Public>echo foo > foo.exe

C:\Users\Public>./foo
'.' is not recognized as an internal or external command,
operable program or batch file.

C:\Users\Public>foo
This version of C:\Users\Public\foo.exe is not compatible with the version of Windows you're running. Check your computer's system information and then contact the software publisher.

C:\Users\Public>del foo.exe

C:\Users\Public>exit



Marc Benford wrote on 07/25/26 at 19:33:39:

I also tried to write the following three lines in the command prompt:
Code
Select All
cd C:\Users\Name\Desktop\popeye-develop\popeye-develop\gengmarr.c
cd C:\Users\Name\Desktop\popeye-develop\popeye-develop\gengmarr.exe
cd C:\Users\Name\Desktop\popeye-develop\popeye-develop\gengmarr.o

But in all three cases, it gives me the following error message:
Code
Select All
The directory name is invalid.

Again this is expected behavior. "cd" is short for "change directory". popeye-develop is a directory, so you can cd into it. gengmarr.c ,  gengmarr.exe , and gengmarr.o are files, so you cannot cd into them.

Marc Benford wrote on 07/25/26 at 19:33:39:
I then added
Code
Select All
echo "1$(eXeCuTe)1"

and when I tried make again, it gave me the exact same error message as before, except that right before the line
Code
Select All
./gengmarr > pygmarr.c

it now says
Code
Select All
echo "11"
"11"

So it seems that $(eXeCuTe) doesn't have the right value.

Actually $(eXeCuTe) is blank, which is what we wanted. It was not what was causing the error message about '.', but it was worth checking. I will let you work out for yourself why "11" was echoed when $(eXeCuTe) is blank. You can delete the echo line, although leaving it in will do no harm.
  
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 #18 - 07/25/26 at 19:33:39
Post Tools
When I type
Code
Select All
gcc -o gengmarr  -O3 -flto   gengmarr.o position/position-host.o position/board-host.o

in the command prompt immediately after opening it, I get the following error message:
Code
Select All
gcc: error: gengmarr.o: No such file or directory
gcc: error: position/position-host.o: No such file or directory
gcc: error: position/board-host.o: No such file or directory
gcc: fatal error: no input files
compilation terminated.


.

When I first type
Code
Select All
cd C:\Users\Name\Desktop\popeye-develop\popeye-develop

and then I type
Code
Select All
gcc -o gengmarr  -O3 -flto   gengmarr.o position/position-host.o position/board-host.o

it doesn't do anything, the command prompt doesn't return any message at all.

.

In the popeye-develop folder, I see a file called pygmarr.c, and I see three gengmarr files:
- gengmarr.c
- gengmarr.exe
- gengmarr.o

.

Quote:
Try running gengmarr from the command prompt, without redirection, and you should get back some C code in the command prompt.
Simply
    ./gengmarr


I'm not sure what to do there.

When I type
Code
Select All
./gengmarr

in the command prompt, I get the following error message:
Code
Select All
'.' is not recognized as an internal or external command,
operable program or batch file.


.

I also tried to write the following three lines in the command prompt:
Code
Select All
cd C:\Users\Name\Desktop\popeye-develop\popeye-develop\gengmarr.c

Code
Select All
cd C:\Users\Name\Desktop\popeye-develop\popeye-develop\gengmarr.exe

Code
Select All
cd C:\Users\Name\Desktop\popeye-develop\popeye-develop\gengmarr.o

But in all three cases, it gives me the following error message:
Code
Select All
The directory name is invalid.


.

I then added
Code
Select All
echo "1$(eXeCuTe)1"

and when I tried make again, it gave me the exact same error message as before, except that right before the line
Code
Select All
./gengmarr > pygmarr.c

it now says
Code
Select All
echo "11"
"11"

So it seems that $(eXeCuTe) doesn't have the right value.
  
Back to top
 
IP Logged
 
an ordinary chessplayer
God Member
*****
Offline


I used to be not bad.

Posts: 1837
Location: Columbus, OH (USA)
Joined: 01/02/15
Re: Chess problem solving softwares like Popeye
Reply #17 - 07/25/26 at 16:13:39
Post Tools
I don't think it was a stupid mistake to try the "#" comment on the same line. Lots of programming languages have a "rest of line" comment like that, but as you found out, make does not.

Marc Benford wrote on 07/25/26 at 09:20:22:

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
'.' is not recognized as an internal or external command,
operable program or batch file.
makefile.local:68: recipe for target 'pygmarr.c' failed
mingw32-make[1]: *** [pygmarr.c] Error 1
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


This one seems to have worked. If you look for a file "gengmarr" it should be there and it should be executable.
Code
Select All
gcc -o gengmarr  -O3 -flto   gengmarr.o position/position-host.o position/board-host.o

Try running gengmarr from the command prompt, without redirection, and you should get back some C code in the command prompt.
Simply
    ./gengmarr
If gengmarr is not there, or if the command doesn't return some proper C code, then we need to fix that. Otherwise we move on.

This one did not work. You may or may not have a file "pygmarr.c", but even if it exists, it is not the pygmarr.c you are looking for.
Code
Select All
./gengmarr > pygmarr.c


Marc Benford wrote on 07/25/26 at 09:20:22:
makefile.local (lines 67-68)
Code
Select All
pygmarr.c: ./gengmarr$(eXe_sUfFiX)
	$(eXeCuTe) ./gengmarr$(eXe_sUfFiX) > $@

Usually on Windows the value of $(eXe_sUfFiX) would be ".exe". It seems under MinGW it is the more unixy "". What is the value of $(eXeCuTe) ? If it is not "" then it might be the problem. You can add a line to your recipe to show that value. 
Code
Select All
pygmarr.c: ./gengmarr$(eXe_sUfFiX)
	echo "1$(eXeCuTe)1"
	$(eXeCuTe) ./gengmarr$(eXe_sUfFiX) > $@

  
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 #16 - 07/25/26 at 09:20:22
Post Tools
Quote:
You should check your local copy of makefile.unx, but I strongly doubt it's any different on line 342.


They are exactly the same. Not a single character is different.

.

I made a stupid mistake. Instead of exactly following your instructions and replacing line 147 of makefile.defaults with
Code
Select All
OsTyPe="Microsoft_Windows-Version11-with_MinGW"

I replaced it with
Code
Select All
OsTyPe="Microsoft_Windows-Version11-with_MinGW"
#OsTyPe=$(OsTaRgEt)-$(OsVeRtArGeT)-$(OsCpUtArGeT)

(I split the above line into two lines because it doesn't display correctly on chesspub.com)

The thing after the # sign is the original version of line 147. I thought that adding a # sign would mean that what's at the right of the # sign is just a comment and that the computer would ignore it. But apparently I was wrong. Because I tried to remove the thing at the right of the # sign, and then I tried make again, and now I get 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
'.' is not recognized as an internal or external command,
operable program or batch file.
makefile.local:68: recipe for target 'pygmarr.c' failed
mingw32-make[1]: *** [pygmarr.c] Error 1
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


It's a clear improvement over the previous error message.

The beginning and the end are the same as the previous error message. But the half in the middle (between "Entering directory" and "Leaving directory") is completely different and much smaller.

Then, I tried to remove the quotes, but this didn't make any difference at all. The error message remains identical.

makefile.local (lines 67-68)
Code
Select All
pygmarr.c: ./gengmarr$(eXe_sUfFiX)
	$(eXeCuTe) ./gengmarr$(eXe_sUfFiX) > $@
  
Back to top
 
IP Logged
 
an ordinary chessplayer
God Member
*****
Offline


I used to be not bad.

Posts: 1837
Location: Columbus, OH (USA)
Joined: 01/02/15
Re: Chess problem solving softwares like Popeye
Reply #15 - 07/25/26 at 04:00:42
Post Tools
LLM is not required for iterating through make errors. It should be obvious we are getting closer.

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

Marc Benford wrote on 07/23/26 at 13:08:23:

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 -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 -dauxiliary position/board.c -o position/board-host.o
0 was unexpected at this time.
makefile.local:52: recipe for target 'position/board-host.o' failed
mingw32-make[1]: *** [position/board-host.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



About the first warning from make "target 'output/latex/nesteddepend' given more than once"

makefile.unx (lines 339-344)
Code
Select All
ifdef DePeNd
depend: $(NeStEdLiBdIrS:%=%/nesteddepend)

$(NeStEdLiBdIrS:%=%/nesteddepend): FoRcE
	$(MAKE) CuRrPwD=$(dir $@) -f $(dir $@)makefile.local depend
endif

  • line 340 - file "depend" depends (sic) on the non-existing file "output/latex/nesteddepend"
  • line 340 does not have a "recipe", not even an empty one, so make should override any existing rule for "depend"
  • line 342 - file "output/latex/nesteddepend" has a _phony_ dependency, so the rule should run every time
    https://www.gnu.org/software/make/manual/html_node/Force-Targets.html
  • line 343 - is the recipe to build "depend" , _not_ "output/latex/nesteddepend". I'm not sure if it's correct code. I would have done it differently but make rules are pretty obscure and this might work for reasons unknown to me.

The head-scratcher though is why make thinks the target is "given more than once", because it's not. You should check your local copy of makefile.unx, but I strongly doubt it's any different on line 342.

Here I'm going to suggest you skip over this one for now. It breaks the suggestion I gave some days ago, which was to fix the 1st error before trying to fix the 2nd error. But since the warning is coming from make and not from gcc, you might be able to get away with it.

About the second error from gcc "0 was unexpected at this time"

99 percent sure that is a parse error. As an educated guess this is due to the different ways Windows and unix handle commandline quotes. Earlier I suggested you change makefile.defaults (line 147), and following my example you used
Code
Select All
OsTyPe="Microsoft_Windows-Version11-with_MinGW"

Now I suggest you remove the quotes.
Code
Select All
OsTyPe=Microsoft_Windows-Version11-with_MinGW

Then try make again.
  
Back to top
 
IP Logged
 
Dink Heckler
God Member
*****
Offline


Love-Forty

Posts: 902
Joined: 02/01/07
Gender: Male
Re: Chess problem solving softwares like Popeye
Reply #14 - 07/24/26 at 07:32:17
Post Tools
I seriously encourage you to work through this with an LLM. Copy-paste all this into eg Claude and it will help you diagnose and fix the errors. Will it get it right first time - probably not, but it will iterate you towards a solution; these tools are really good for this sort of thing.
« Last Edit: 07/24/26 at 12:46:10 by Dink Heckler »  
'Am I any good at tactics?'
'Computer says No!'
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 #13 - 07/23/26 at 13:08:23
Post Tools
Okay, I went with the simpler option (2) as you recommended, and I did not forget to put the word toolchain in uppercase, and here is the error message that I get now (again, I transformed many uppercase letters into lowercase letters):

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 -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 -dauxiliary position/board.c -o position/board-host.o
0 was unexpected at this time.
makefile.local:52: recipe for target 'position/board-host.o' failed
mingw32-make[1]: *** [position/board-host.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


A lot of it is the same as the previous error message. But many parts of it are different.

.

The first difference is that, in the extremely long line (you have to scroll horizontally to see it in full) that starts with gcc -W -Wall, five of the -W* strings have disappeared.

.

The second difference is that this
-c -dauxiliary gengmarr.c -o gengmarr.o
has turned into this
-c -dauxiliary position/board.c -o position/board-host.o

.

The third difference is that all the "gcc: error: unrecognized command line option" have disappeared. So we're making progress.

.

The fourth difference is that this
Code
Select All
makefile.local:60: recipe for target 'gengmarr.o' failed
mingw32-make[1]: *** [gengmarr.o] Error 1

has turned into this
Code
Select All
0 was unexpected at this time.
makefile.local:52: recipe for target 'position/board-host.o' failed
mingw32-make[1]: *** [position/board-host.o] Error 255


.

makefile.local (lines 50-54)
Code
Select All
# 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


.

Take all your time. I'm in no rush.
  
Back to top
 
IP Logged
 
an ordinary chessplayer
God Member
*****
Offline


I used to be not bad.

Posts: 1837
Location: Columbus, OH (USA)
Joined: 01/02/15
Re: Chess problem solving softwares like Popeye
Reply #12 - 07/23/26 at 01:47:49
Post Tools
Hi, I am on vacation and will not log on frequently. But I have not forgotten you.

Note that I had to lower-case "toolchain" everywhere.

Marc Benford wrote on 07/19/26 at 02:01:23:

I used Ctrl+F and searched for the strings in the unrecognized command line options: Walloc, Wduplicated, Wformat. But these strings don't appear in any of the makefiles.

Right.

makefile.unx (lines 29-31)
Code
Select All
# don't put this into the same include as makefile.defaults!
# makefile.defaults defines toolchain
include toolchains/$(toolchain)/make.incl

makefile.defaults (line 198)
Code
Select All
toolchain=gcc

toolchains/gcc/make.incl (lines 53-78)
Code
Select All
# Select warning level
ifeq ($(toolchain), gcc)
WARN=\
  -W \
  -Wall \
  -Wextra \
  -Wpedantic -pedantic-errors \
  -Walloc-zero -Walloca \
  -Warray-bounds=2 \
  -Wcast-align -Wconversion -Wbad-function-cast -Wno-cast-qual \
  -Wduplicated-branches -Wduplicated-cond \
  -Wfloat-equal \
  -Wformat=2 -Wformat-overflow=2 -Wformat-signedness -Wformat-truncation=2 -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


All those -W* strings are types of warnings which you are asking gcc to report on. "unrecognized command line option" means your version of gcc does not recognize that type of warning.

Basically you have two choices.
  1. Get a different gcc which does recognized those warnngs.
  2. Use your existing gcc and remove (delete) the unrecognized warnings from make.incl


I recommend trying the simpler option (2), and only if that doesn't work then go with the more complicated option (1).

After deleting the five unrecognized warnings, the new lines of make.incl (was 53-78, now 53-77)
Code
Select All
# Select warning level
ifeq ($(toolchain), gcc)
WARN=\
  -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


Of course it's likely you will get new errors.
  
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 #11 - 07/19/26 at 02:01:23
Post Tools
Note that in this post, I transformed many uppercase letters into lowercase letters, so that the forum's anti-spam software would not prevent me from posting.



Quote:
What you want to do is go to line 105 which begins defs= and at the end of that line add a space followed by (translate the following to all-caps)  $(definemacro)sharing
Okay, I did that, and then when I typed mingw32-make -f makefile.unx in the command prompt, it gave me the same large error message as before.



Quote:
change line 147 to:
ostype="Microsoft_Windows-Version11-with_MinGW"
I am indeed using Windows 11. The Windows ver command more precisely says "version 25H2 (OS Build 26200.8875). I changed this line, and then when I typed mingw32-make -f makefile.unx in the command prompt, it gave me again the same large error message as before. No progress.



Here is the error message in full:
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 -W -Wall -Wextra -Wpedantic -pedantic-errors -Walloc-zero -Walloca -Warray-bounds=2 -Wcast-align -Wconversion -Wbad-function-cast -Wno-cast-qual -Wduplicated-branches -Wduplicated-cond -Wfloat-equal -Wformat=2 -Wformat-overflow=2 -Wformat-signedness -Wformat-truncation=2 -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 -dauxiliary gengmarr.c -o gengmarr.o
gcc: error: unrecognized command line option '-Walloc-zero'; did you mean '-Wdiv-by-zero'?
gcc: error: unrecognized command line option '-Walloca'; did you mean '-Wall'?
gcc: error: unrecognized command line option '-Wduplicated-branches'; did you mean '-Wduplicated-cond'?
gcc: error: unrecognized command line option '-Wformat-overflow=2'; did you mean '-Wstrict-overflow='?
gcc: error: unrecognized command line option '-Wformat-truncation=2'; did you mean '-Wline-truncation'?
makefile.local:60: recipe for target 'gengmarr.o' failed
mingw32-make[1]: *** [gengmarr.o] Error 1
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




In the middle of the error message, it says:
-dostype=\""Microsoft_Windows-Version11-with_MinGW"\"
Which is what I changed line 147 into. I'm not sure what exactly the error message said there before I modified line 147.



Quote:
There may have been some errors in DELETED, I can't tell. But for the sake of the process let's assume the unrecognized command line option is the first error.
There were indeed some errors in DELETED.
gcc: error: unrecognized command line option '-r`-`uname -p`"
was not the first error. There were other gcc errors before this one. In fact, it seems that this gcc error disappeared, perhaps because I changed line 147.

I used Ctrl+F and searched for the strings in the unrecognized command line options: Walloc, Wduplicated, Wformat. But these strings don't appear in any of the makefiles.



Note that there is a file called "gengmarr.c", and the word "gengmarr" appears four times in the large error message.
Code
Select All
-c -dauxiliary gengmarr.c -o gengmarr.o

Code
Select All
makefile.local:60: recipe for target 'gengmarr.o' failed
mingw32-make[1]: *** [gengmarr.o] Error 1

The word "gengmarr" also appears on line 59 and line 63 of makefile.local.
  
Back to top
 
IP Logged
 
an ordinary chessplayer
God Member
*****
Offline


I used to be not bad.

Posts: 1837
Location: Columbus, OH (USA)
Joined: 01/02/15
Re: Chess problem solving softwares like Popeye
Reply #10 - 07/18/26 at 16:38:05
Post Tools
Marc Benford wrote on 07/18/26 at 00:37:29:
DELETED
gcc: error: unrecognized command line option '-r`-`uname -p`"'
makefile.local:60: recipe for target 'gengmarr.o' failed
mingw32-make[1]: *** [gengmarr.o] Error 1

Okay when you see error output from make, you should tackle the first one first, because if the first error is causing the second error, then removing the first error fixes both, and the corollary is, until you remove the first error, you will never get rid of the second one.

There may have been some errors in DELETED, I can't tell. But for the sake of the process let's assume the unrecognized command line option is the first error. Here is how you would go about fixing it.

The first place to look is line 60 in makefile.local , but that wasn't too helpful.

The second thing to look for is the string in the unrecognized command line option. Searching makefile.defaults for uname I found lines 143-147, which corrected for all-caps read:
Code
Select All
ostarget=`uname`
osvertarget=`uname -r`
oscputarget="`uname -p`"

OSTYPE=$(ostarget)-$(osvertarget)-$(oscputarget)

When I run those same three commands on my Linux box I get:
    $ uname
    Linux
    $ uname -r
    6.5.0-1mx-ahs-amd64
    $ uname -p
    unknown
    $ 

The backticks are a unixy way of saying `insert the result of this command`, but it's not working on Windows. Instead of the _result_ of the uname commands, you are getting the commands themselves, and your OSTYPE is getting the string "uname-uname -r-uname -p". There are various ways you can fix this, but the absolute simplest is to just hard-code the result string in the makefile. For example change line 147 to:
Code
Select All
OSTYPE="Microsoft_Windows-Version11-with_MinGW"

Or whatever you want it to say, I don't think it matters. If you are fussy you can use the result of the Windows ver command. I recommend against any spaces or "special" characters like brackets in the string though.

If that fixes the error on makefile.local:60 , you can move on to the next one.
  
Back to top
 
IP Logged
 
an ordinary chessplayer
God Member
*****
Offline


I used to be not bad.

Posts: 1837
Location: Columbus, OH (USA)
Joined: 01/02/15
Re: Chess problem solving softwares like Popeye
Reply #9 - 07/18/26 at 15:52:18
Post Tools
Marc Benford wrote on 07/18/26 at 00:22:24:
It's like reading Chinese. It's hopeless.

Documentation that assumes you already know all the lingo. But not hopeless, because you can make a decent guess and get detailed error messages from make about what went wrong. When there are no more error messages, you will have a working Popeye.

Marc Benford wrote on 07/18/26 at 00:22:24:
The line with the word "SHARING" is line 63.
How exactly do I "uncomment" it?

You would uncomment exactly the way you tried, by removing the leading #. Bad it was a bad instruction on my part. What you want to do is go to line 105 which begins DEFS= and at the end of that line add a space followed by (translate the following to all-caps)  $(definemacro)sharing

Marc Benford wrote on 07/18/26 at 00:22:24:
What even is a "separator"?

For a Makefile, the separator is the TAB character, which takes some getting used to. make saw 8 spaces and asked if you meant TAB instead. Don't worry about it on line 63 because you don't want either one, you want to edit line 105.
  
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 #8 - 07/18/26 at 00:37:29
Post Tools
So I put the # character back, and then when I type "mingw32-make -f makefile.unx", it gives me the following large error message:

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 -W -Wall -Wextra -Wpedantic -pedantic-errors -Walloc-zero 
DELETED
gcc: error: unrecognized command line option '-r`-`uname -p`"'
makefile.local:60: recipe for target 'gengmarr.o' failed
mingw32-make[1]: *** [gengmarr.o] Error 1
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

I had to cut half of the error message, because Chesspub.com keeps saying "It appears that you are trying to write using ALL CAPS - Please be aware this is against forum rules." If the spam detection software is too permissive, then the forum will be flooded with spam. But if it is not permissive enough, then it will sometimes prevent members from posting real messages. It's a dilemma.
  
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 #7 - 07/18/26 at 00:22:24
Post Tools
Quote:
But Popeye doen't have that file, instead it has a few makefile.* . Read all of them to see what options you might need for Windows.

I read them, but I didn't understand them. It's like reading Chinese. It's hopeless.



Quote:
Then try make with the option `-f makefile.unx`

Step 1: Open the command prompt.

Step 2: I must either type "cd C:\Users\Name\Desktop\popeye-develop" or "cd C:\Users\Name\Desktop\popeye-develop\popeye-develop". I already don't know which one of these two things I must type. Because, after I downloaded Popeye from GitHub, I now have a file (maybe "file" is not the right name, maybe it's called a "folder" instead, I don't know) called "popeye-develop" on my computer, and inside this file there's only one file and it's also called "popeye-develop", and inside this file are all the very many files. So when I want to try something, I first type "cd C:\Users\Name\Desktop\popeye-develop" and then I try the thing, and if it doesn't work then I type "cd C:\Users\Name\Desktop\popeye-develop\popeye-develop" and then I try the thing again to see if it works this time...

Step 3: And so on step 3, you want me to then type "make -f makefile.unx"? Is that right? It gives me the following error:
'make' is not recognized as an internal or external command, operable program or batch file.
Perhaps I should instead type "mingw32-make -f makefile.unx"? This seems to give slightly better results, but it still doesn't work.



Quote:
in makefile.defaults there is a line with SHARING you will probably want to uncomment.

The line with the word "SHARING" is line 63.
How exactly do I "uncomment" it?
I tried removing the #, but then the command prompt gave me the following error message when I tried make:
makefile.defaults:63: *** missing separator (did you mean TAB instead of 8 spaces?).  Stop.
So I removed all of the whitespace characters, but then the command prompt gave me the following error message when I tried make:
makefile.defaults:63: *** missing separator.    Stop.
What even is a "separator"?
  
Back to top
 
IP Logged
 
an ordinary chessplayer
God Member
*****
Offline


I used to be not bad.

Posts: 1837
Location: Columbus, OH (USA)
Joined: 01/02/15
Re: Chess problem solving softwares like Popeye
Reply #6 - 07/17/26 at 17:03:10
Post Tools
It's been a long time since I compiled with gcc on Windows. Back then mingw didn't even exist, and I didn't use cygwin either, so let's just skip over my "experience".

It looks like you installed mingw correctly, but the internet examples for how to use it show how to compile a single-file .c into .exe .

Popeye is much more complex than that, and to manage all the options and dependencies there is the command make . By default make gets its options from Makefile. But Popeye doen't have that file, instead it has a few makefile.* .

Read all of them to see what options you might need for Windows. For example in makefile.defaults there is a line with SHARING you will probably want to uncomment. Then try make with the option `-f makefile.unx`

https://stackoverflow.com/questions/12881854/how-to-use-gnu-make-on-windows
  
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 #5 - 07/16/26 at 17:12:56
Post Tools
Okay, so I downloaded all the Popeye files and I edited them to add a new piece. This is done. What now? I think this is the part where I need to compile the Popeye files, after which I will obtain a .exe file. I have never compiled anything in my life, so I need some help on that. I don't even know what "compiling" even means, but apparently this is what I must do.

I installed the following three things on my computer:
- MinGW (GCC for Windows) (I needed to watch a Youtube tutorial to figure out how to install this one)
- Git
- Node

In the command prompt, I type "cd C:\Users\Name\Desktop\popeye-develop" to navigate to the location of the Popeye files. Then, I type "gcc popeye-develop" to compile the Popeye files, but it just gives me the following error message:
c:/mingw/bin/../lib/gcc/mingw32/6.3.0/../../../../mingw32/bin/ld.exe: cannot find popeye-develop: Permission denied
collect2.exe: error: ld returned 1 exit status
  
Back to top
 
IP Logged
 
an ordinary chessplayer
God Member
*****
Offline


I used to be not bad.

Posts: 1837
Location: Columbus, OH (USA)
Joined: 01/02/15
Re: Chess problem solving softwares like Popeye
Reply #4 - 07/14/26 at 22:14:48
Post Tools
https://github.com/thomas-maeder/popeye

Popeye is designed to accomodate arbitrary pieces! The most recent was Scarabeus, added last year. There are 162 different pieces in pieces.h, plus Empty, Invalid, and Hunter0; I think the last one is a semaphore.

I would not overwrite an existing piece with new movements, but rather use the existing piece as a template, add code in all the appropriate modules, and then modify the copied code. Very little C knowledge is required because you are not programming from scratch. The hard part is making sure you touch all the necessary modules. Maybe the developer/maintainer would work with you on that part. In return you could offer to write up a document "How to add a new piece to Popeye". For writing such a document, which you would want anyway when it is time to add your second piece,  not knowing C might be an advantage -- you would write very detailed notes which could then be followed by all fairy enthusiasts who might also not know C.

Another approach for finding all the needed places would be to do a diff on the commit that added Scarabeus. Some git skills required for that step.
  
Back to top
 
IP Logged
 
Dink Heckler
God Member
*****
Offline


Love-Forty

Posts: 902
Joined: 02/01/07
Gender: Male
Re: Chess problem solving softwares like Popeye
Reply #3 - 07/14/26 at 12:54:46
Post Tools
Unironically sounds like a job for vibe coding.
  
'Am I any good at tactics?'
'Computer says No!'
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 #2 - 07/14/26 at 08:11:42
Post Tools
Thank you. Your answer is helpful.

Yes, I could perhaps change the code that defines how a piece move. This is a good idea. For example, if I want a (2,6)-leaper (I don't, but this is just a made up example), I could find the line of code that defines the move of say the (1,2)-leaper, also known as the knight, and change the numbers (1,2) into (2,6). Then when I will use the letter S (which strangely is the symbol of the knight in Popeye), it won't be a knight but a (2,6)-leaper.

But this will be difficult, because I have never done anything like that, and because I don't know the C programming language. How do I even see Popeye's C code? Where do I find "board.h" and "board.c"? The only Popeye file I see on my computer is called "pywin64.exe": when I click on it, this launches Popeye.

I don't think that XBoard and the FairyMax engine are what I am looking for. I don't want a graphical user interface chessboard. I don't want a general purpose engine. I want a chess problem solving software like Popeye that just blindly calculates every possible line until checkmate.
« Last Edit: 07/14/26 at 16:37:40 by Marc Benford »  
Back to top
 
IP Logged
 
an ordinary chessplayer
God Member
*****
Offline


I used to be not bad.

Posts: 1837
Location: Columbus, OH (USA)
Joined: 01/02/15
Re: Chess problem solving softwares like Popeye
Reply #1 - 07/13/26 at 00:30:11
Post Tools
If you are looking to define a new piece via the GUI, that would be a heavy lift. I sincerely doubt anybody has made that possible. In Popeye you could (in principle) add a new piece in the c code. Instead I suggest you check out the FairyMax engine, which uses a file fmax.ini to define the variants and the piece movements. It's still complicated, but if your piece combinations are simple you might be able to figure it out. For example look at the Queen, look at the Knight, look at the Amazon, and see in what way the Queen and Knight were combined there. Then try the same thing with your desired piece combination.

For resizing the board, both Xboard(Winboard) and Popeye can do it. In Xboard you can change the size of the board _larger_ on the fly by providing a larger FEN. But if you try to make it smaller with the same trick then it will complain. There are command-line options as well which you can read up on. With Popeye you can change the size of the board by editing board.h and compiling. In board.c the defined files go from a to z, so it should probably handle up to a 26x26 board this way.
 
Lines in board.h to change:
Code
Select All
  nr_files_on_board = 8,
  nr_rows_on_board = 8,
  
Back to top
 
IP Logged
 
Marc Benford
Full Member
***
Offline


I Love ChessPublishing!

Posts: 147
Joined: 07/17/13
Chess problem solving softwares like Popeye
07/11/26 at 21:27:15
Post Tools
I am looking for chess problem solving softwares that handle fairy pieces, like Popeye. Except that I want a software where I can create my own fairy pieces, and I want a software where I can change the size of the board. The first thing is much more important to me than the second. I don't necessarily need one software that does both of these things. I can also go with one software that does the first thing and a different software that does the second thing, that would be perfectly fine.

As far as I know, I can't do any of these two things on Popeye. Popeye has a list of about 130 fairy pieces. If the piece I want is not in the list, then I can't use that piece.

I don't need to create complicated pieces, like asymmetrical pieces or pieces that don't move the same way they capture. I just need to combine two simple pieces.
  
Back to top
 
IP Logged
 
Page Index Toggle Pages: [1] 
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