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


I used to be not bad.

Posts: 1831
Location: Columbus, OH (USA)
Joined: 01/02/15
Re: Chess problem solving softwares like Popeye
Reply #59 - Today 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.


  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 ming32-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/
        ming32-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
  
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 - Today 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 - Today 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 - Today 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 - Today 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 - Today 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 - Today 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 - Today 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 - Today 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 - Today 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 - Today 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 - Today 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 - Today 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 - Today 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 - Today 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
 
Page Index Toggle Pages: [1] 2 3 4
Topic Tools
‹ Previous Topic | Next Topic ›
Bookmarks: del.icio.us Digg Facebook Google Google+ Linked in reddit StumbleUpon Twitter Yahoo
 
  « Board Index ‹ Board Top  

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

Valid RSS Valid XHTML Valid CSS Powered by Perl Source Forge