(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] 2 3 
Topic Tools
Very Hot Topic (More than 25 Replies) Chess problem solving softwares like Popeye (Read 1392 times)
an ordinary chessplayer
God Member
*****
Offline


I used to be not bad.

Posts: 1830
Location: Columbus, OH (USA)
Joined: 01/02/15
Re: Chess problem solving softwares like Popeye
Reply #34 - Today 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: 123
Joined: 07/17/13
Re: Chess problem solving softwares like Popeye
Reply #33 - Today 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: 123
Joined: 07/17/13
Re: Chess problem solving softwares like Popeye
Reply #32 - Today 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: 123
Joined: 07/17/13
Re: Chess problem solving softwares like Popeye
Reply #31 - Today 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: 123
Joined: 07/17/13
Re: Chess problem solving softwares like Popeye
Reply #30 - Today 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: 123
Joined: 07/17/13
Re: Chess problem solving softwares like Popeye
Reply #29 - Today 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: 123
Joined: 07/17/13
Re: Chess problem solving softwares like Popeye
Reply #28 - Today 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: 1830
Location: Columbus, OH (USA)
Joined: 01/02/15
Re: Chess problem solving softwares like Popeye
Reply #27 - Today at 14:45:57
Post Tools
Marc Benford wrote Today 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: 1830
Location: Columbus, OH (USA)
Joined: 01/02/15
Re: Chess problem solving softwares like Popeye
Reply #26 - Today 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: 123
Joined: 07/17/13
Re: Chess problem solving softwares like Popeye
Reply #25 - Today 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: 1830
Location: Columbus, OH (USA)
Joined: 01/02/15
Re: Chess problem solving softwares like Popeye
Reply #24 - Today 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 | 1 Download )
Back to top
 
IP Logged
 
an ordinary chessplayer
God Member
*****
Offline


I used to be not bad.

Posts: 1830
Location: Columbus, OH (USA)
Joined: 01/02/15
Re: Chess problem solving softwares like Popeye
Reply #23 - Today 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: 123
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: 123
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: 1830
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
 
Page Index Toggle Pages: [1] 2 3 
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