cmake can not be used without patching cmake-utils.eclass, because the prefix handling falsely assumes that Cygwin prefixes are like all Non-APPLE prefixes. Reproducible: Always Steps to Reproduce: 1. Try to build anything (cmake including) that uses cmake Actual Results: --- In configure stage --- -- Check for working C compiler: /gentoo/usr/bin/x86_64-pc-cygwin-gcc.exe -- Check for working C compiler: /gentoo/usr/bin/x86_64-pc-cygwin-gcc.exe -- broken CMake Error at /gentoo/usr/share/cmake/Modules/CMakeTestCCompiler.cmake:52 (message): The C compiler "/gentoo/usr/bin/x86_64-pc-cygwin-gcc.exe" is not able to compile a simple test program. It fails with the following output: Change Dir: /build/portage/media-libs/phonon-4.9.1-r1/work/phonon-4.9.1-qt5/CMakeFiles/CMakeTmp Run Build Command:"/gentoo/usr/bin/gmake.exe" "cmTC_1047c/fast" /gentoo/usr/bin/gmake -f CMakeFiles/cmTC_1047c.dir/build.make CMakeFiles/cmTC_1047c.dir/build gmake[1]: Entering directory '/build/portage/media-libs/phonon-4.9.1-r1/work/phonon-4.9.1-qt5/CMakeFiles/CMakeTmp' Building C object CMakeFiles/cmTC_1047c.dir/testCCompiler.c.o /gentoo/usr/bin/x86_64-pc-cygwin-gcc.exe -DNDEBUG -march=native -O2 -pipe -o CMakeFiles/cmTC_1047c.dir/testCCompiler.c.o -c /build/portage/media-libs/phonon-4.9.1-r1/work/phonon-4.9.1-qt5/CMakeFiles/CMakeTmp/testCCompiler.c Linking C executable cmTC_1047c.exe /gentoo/usr/bin/cmake.exe -E cmake_link_script CMakeFiles/cmTC_1047c.dir/link.txt --verbose=1 /gentoo/usr/bin/x86_64-pc-cygwin-gcc.exe -march=native -O2 -pipe -Wl,--enable-auto-import -L/gentoo/usr/bin -L/gentoo/bin -L/gentoo/usr/lib -L/gentoo/lib CMakeFiles/cmTC_1047c.dir/testCCompiler.c.o -o cmTC_1047c.exe -Wl,--out-implib,libcmTC_1047c.dll.a -Wl,--major-image-version,0,--minor-image-version,0 /gentoo/usr/x86_64-pc-cygwin/lib/gcc /gentoo/usr/x86_64-pc-cygwin/lib /gentoo/usr/lib /gentoo/lib /gentoo/usr/x86_64-pc-cygwin/lib/gcc: file not recognized: Is a directory collect2: error: ld returned 1 exit status gmake[1]: *** [CMakeFiles/cmTC_1047c.dir/build.make:98: cmTC_1047c.exe] Error 1 gmake[1]: Leaving directory '/build/portage/media-libs/phonon-4.9.1-r1/work/phonon-4.9.1-qt5/CMakeFiles/CMakeTmp' gmake: *** [Makefile:126: cmTC_1047c/fast] Error 2 CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:1 (project) -- Configuring incomplete, errors occurred! Expected Results: Should work just fine. The resolution, once I found out why this was happening, is luckily quite simple. CMake on Cygwin prefix does not understand CMAKE_PLATFORM_REQUIRED_RUNTIME_PATH, so it does not add the supplied paths as intended, but simply dumps them to the command line, which leads to the above error. The solution is to simply handle CYGWIN like APPLE.
Created attachment 515224 [details, diff] fix_cmake-utils.eclass_for_cygwin.patch This patch let's CYGWIN prefixes to be handled like APPLE ones. Further I am playing safe and make sure that WIN32 is definitely *not* set. The letter should be superfluous, but it doesn't hurt either.
I am pretty sure discovering this bug is the best thing that happened to me today so far. Thanks!
Why has this been assigned to @kde? Should we reassign to @prefix?
I think because kde is the owner of the eclass
Please rebase your patch against cmake.eclass and send it to gentoo-dev mailing list for review.
Ping, is this still necessary? Please note that cmake-utils.eclass is deprecated and any fixes only go into cmake.eclass.
Sorry folks, I have totally forgotten about this bug. With Gentoo running perfectly fine in WSL, I haven't used Cygwin with Gentoo Prefix for over a year now. I don't even know if any patch is still needed. More than this, I found Cygwin to be a dead end on many aspects. Their forking issues continue, and disk access is hilariously slow. Their own software works well, and I no longer see any advantage in plugging a Gentoo Prefix into that. Well, other than to prove that is possible. So from my point of view, this bug could as well be closed. Again, I fully apologize to have forgotten about this issue!
(In reply to Sven Eden from comment #7) > Sorry folks, I have totally forgotten about this bug. > > With Gentoo running perfectly fine in WSL, I haven't used Cygwin with Gentoo > Prefix for over a year now. > > I don't even know if any patch is still needed. > > More than this, I found Cygwin to be a dead end on many aspects. Their > forking issues continue, and disk access is hilariously slow. Their own > software works well, and I no longer see any advantage in plugging a Gentoo > Prefix into that. Well, other than to prove that is possible. The question is if native Windows binaries like MSVC toolchain (cl.exe&co) can be run from within WSL these days. As soon as that one does reliably work, we indeed have no real need for Cygwin any more as well. > So from my point of view, this bug could as well be closed. As we've phased out Subversion here, we don't have need for CMake on Cygwin any more too.