Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 644926 - [prefix/cygwin] cmake.eclass is broken for cygwin prefix
Summary: [prefix/cygwin] cmake.eclass is broken for cygwin prefix
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo/Alt
Classification: Unclassified
Component: Prefix Support (show other bugs)
Hardware: All Linux
: Normal major (vote)
Assignee: Gentoo KDE team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-01-18 09:47 UTC by Sven Eden
Modified: 2020-08-24 07:02 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
fix_cmake-utils.eclass_for_cygwin.patch (fix_cmake-utils.eclass_for_cygwin.patch,1.48 KB, patch)
2018-01-18 09:49 UTC, Sven Eden
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Sven Eden 2018-01-18 09:47:49 UTC
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.
Comment 1 Sven Eden 2018-01-18 09:49:15 UTC
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.
Comment 2 Greg Turner 2018-04-24 10:14:00 UTC
I am pretty sure discovering this bug is the best thing that happened to me today so far.  Thanks!
Comment 3 Guilherme Amadio gentoo-dev 2018-08-20 09:56:01 UTC
Why has this been assigned to @kde? Should we reassign to @prefix?
Comment 4 Fabian Groffen gentoo-dev 2018-08-20 10:22:17 UTC
I think because kde is the owner of the eclass
Comment 5 Andreas Sturmlechner gentoo-dev 2020-01-04 10:57:37 UTC
Please rebase your patch against cmake.eclass and send it to gentoo-dev mailing list for review.
Comment 6 Andreas Sturmlechner gentoo-dev 2020-07-22 15:26:00 UTC
Ping, is this still necessary? Please note that cmake-utils.eclass is deprecated and any fixes only go into cmake.eclass.
Comment 7 Sven Eden 2020-08-23 15:11:52 UTC
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!
Comment 8 Michael Haubenwallner (RETIRED) gentoo-dev 2020-08-24 07:02:30 UTC
(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.