Cmake troubles under Cygwin and MSYS2 about goldfish HOT 8 CLOSED

Strange. There is nothing added between v1.11.1 and v1.11.2 that touches the compiler detection - in fact, there's never been anything handling that, as CMake is supposed to do that. Both methods (export CC and -DCMAKE_C_COMPILER) should work, assuming you provide valid paths. But the log here seems to show that a GNU compiler is found just fine, as it found something that identifies as GNU 7.3.0. If g++ is an alias that points to /usr/bin/cc, which itself is the GNU compiler, that makes sense.

Regardless, it doesn't seem like the compiler is actually the issue. The error message seems to show that /bin/sh tried to execute /usr/bin/cmake.exe but did not find such a file. Possibly an installation issue of CMake, or Cygwin not playing nice with it, or some combination.

I suspect this doesn't have anything to do with Goldfish. To verify, try putting this into a file named CMakeLists.txt and save it in an empty folder:

cmake_minimum_required(VERSION 3.10)  # Or some lower version if need be
project(Dummy LANGUAGES C CXX)

and then run

> cmake path/to/above/CMakeLists.txt

If this fails similarly, at least you know its a setup issue. If not, please let me know! I can't reproduce this in any way, so it's a bit hard to sort out.

from goldfish.

Issue title adjusted as I much prefer MSYS2 to Cygwin, and got a new MSYS2 install to test.

Bendik, I finally got to make Cmake work with your test CMakeLists.txt.

I had to add -G "MinGW Makefiles" to the command line otherwise I got this:

# cmake CMakeLists.txt
-- Building for: NMake Makefiles
-- The C compiler identification is unknown
-- The CXX compiler identification is GNU 8.3.0
CMake Error at CMakeLists.txt:2 (project):
  The CMAKE_C_COMPILER:

    cl

  is not a full path and was not found in the PATH.

  To use the NMake generator with Visual C++, cmake must be run from a shell
  that can use the compiler cl from the command line.  This environment is
  unable to invoke the cl compiler.  To fix this problem, run cmake from the
  Visual Studio Command Prompt (vcvarsall.bat).

  Tell CMake where to find the compiler by setting either the environment
  variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to
  the compiler, or to the compiler name if it is in the PATH.


-- Check for working CXX compiler: C:/msys64/mingw64/bin/g++.exe
CMake Error: Generator: execution of make failed. Make command was: "nmake" "/nologo" "cmTC_93276\fast"
-- Check for working CXX compiler: C:/msys64/mingw64/bin/g++.exe -- broken
CMake Error at C:/msys64/mingw64/share/cmake-3.13/Modules/CMakeTestCXXCompiler.cmake:45 (message):
  The C++ compiler

    "C:/msys64/mingw64/bin/g++.exe"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: C:/msys64/home/admin/goldfish-1120/build/CMakeFiles/CMakeTmp

    Run Build Command:"nmake" "/nologo" "cmTC_93276\fast"
    The system cannot find the file specified
    Generator: execution of make failed. Make command was: "nmake" "/nologo" "cmTC_93276\fast"




  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:2 (project)


-- Configuring incomplete, errors occurred!
See also "C:/msys64/home/admin/goldfish-1120/build/CMakeFiles/CMakeOutput.log".
See also "C:/msys64/home/admin/goldfish-1120/build/CMakeFiles/CMakeError.log".

Then I got this:

# cmake -G "MinGW Makefiles" CMakeLists.txt
CMake Error at C:/msys64/mingw64/share/cmake-3.13/Modules/CMakeMinGWFindMake.cmake:12 (message):
  sh.exe was found in your PATH, here:

  C:/msys64/usr/bin/sh.exe

  For MinGW make to work correctly sh.exe must NOT be in your path.

  Run cmake from a shell that does not have sh.exe in your PATH.

  If you want to use a UNIX shell, then use MSYS Makefiles.

Call Stack (most recent call first):
  CMakeLists.txt:2 (project)


CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!

and only after renaming sh.exe in /usr/bin it completed without errors:

# cmake -G "MinGW Makefiles" CMakeLists.txt
-- The C compiler identification is GNU 8.3.0
-- The CXX compiler identification is GNU 8.3.0
-- Check for working C compiler: C:/msys64/mingw64/bin/gcc.exe
-- Check for working C compiler: C:/msys64/mingw64/bin/gcc.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: C:/msys64/mingw64/bin/g++.exe
-- Check for working CXX compiler: C:/msys64/mingw64/bin/g++.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: C:/msys64/home/admin/goldfish-1120/build

Next step is compiling Goldfish now that there is a makefile ready. Currently make just displays version info and dumps me back to the prompt -- apparently it didn't take kindly to me renaming sh.exe. I'll try after a reboot.

from goldfish.

-G "MinGW Makefiles" was wrong, should be "MSYS Makefiles" instead. With that correction I was able to compile Goldfish without problems.

So the complete cmdline is

cmake .. -G "MSYS Makefiles" -DCMAKE_CXX_COMPILER=g++ -DCMAKE_BUILD_TYPE=Release

About Goldfish stalling and losing on time. I think I narrowed the problem to a dependency incompatibility. Managed to reproduce it on a Win 2012 Server box that has MS VC++ 2017 redistributable installed, under both Cute Chess and Arena. A static build solved this problem, although it's about 15x larger: goldfish-1120-x64-tp.

It would be a good idea to make future releases staticl. The build instructions could be updated with the above info, too.

from goldfish.

@tpoppins Sorry for the late reply!

About the different build systems (the -G options): This is highly setup dependent, and unique to what software you have installed. Even though I had a MS Visual Studio installation on my Windows machine, it complained about not having the MSYS Makefile build system. If this worked for you that's great, but also not a general solution.

I've managed to sort out the installation process to something I (hope) should work in most cases. Using Cygwin, you can use the setup installer to chose several packages. Chosing gcc, g++, cmake and make from recent versions makes it work just as easily as on a Unix system. Simply doing

$ mkdir /path/to/goldfish/repo/build && cd /path/to/goldfish/repo/build
$ cmake .. -DCMAKE_BUILD_TYPE=Release
$ make goldfish.x

seems to work great then. I've also updated the build instructions in the README with this.

Lastly, about the static build, I agree. That seems to be the most stable solution. A static pre-compiled executable is available for the most recent version at https://github.com/bsamseth/Goldfish/releases

If you can confirm that this works for you we could (hopefully) close this issue.

Thanks again for the feedback and help.

from goldfish.

There are three issues with the provided v1.13.0 exec.

1. It's missing the ".exe" extension. The references to "goldfish.x" in compiling instructions and files needs to be corrected as well, ".x" is not a valid extension for Win execs.

2. It works on this Win7 box but crashes on the aforementioned Win 2012 Server one with this error msg:
   https://i.postimg.cc/wB4Kf4HX/goldfish-1130-error.png

"The procedure entry point __sprintf_chk could not be located in the dynamic link library \Goldfish.v1.13.0.64bit.exe"

I had a look at it and it turns out that it needs the latest cygwin1.dll (v3000.4.0.0). Odd that the one just three months old I had on that box is not good enough. Goldfish likes living on the edge, eh? :>

Which leads to the next issue.

3. Despite being at least three times larger than my static compile -- and about 50x (!) the size of the official v1.12.0 exec -- it's not a static compile. Of course, no Cygwin compiles really are as they need cygwin1.dll, but once I got it running I could see it has around 20 dependencies compared to the three of my MSYS compile.

You can see why I'm not particularly fond of Cygwin.

from goldfish.

Wow. I and thought I had it this time! Oh well.

1. That was my bad, I simply forgot to re-add the .exe when I manually renamed the file. They are added by CMake/Make, I just messed that one up.

2. I didn't realize Cygwin did this, but my bad for not testing it outside of Cygwin before I uploaded. I got the same error just by running the exec outside of Cygwin.

3. That's a bummer. I was really hoping this would work properly.

Update:

I've updated the exec. for v1.13.0 over at the release page. The current build is using the MinGW toolchain, which seems to have sorted out all the issues (at least that I can find!). I've tested this to work without issue both on the Windows server I used to build it, but also on a more or less fresh Windows 10 installation (which has never been touched by Cygwin, MinGW or any build tools at all). So that will hopefully sort out most issues!

Note: The build is with popcount hardware support, so it might not work on older hardware. Could make a build without, but I'm not sure if this is needed by anyone(?).

from goldfish.

If this does indeed work for you as well, I'll update the build instructions accordingly.

from goldfish.

Yes, this build works fine and has only five dependencies, all common Windows files.

As for POPCNT all three of my test boxes support it. Graham, our other main 40/40 tester, has one that doesn't, although his focus is on higher-rated engines (2300 Elo and up). I would provide a base x64 build just for Guenther Simon, the author of the most comprehensive engine resource online -- RWBC Chronology. His system is an old AMD with support for up to SSE3.

from goldfish.