Bug 964681 - cmake broken under MinGW
cmake broken under MinGW
Product: Fedora
Classification: Fedora
Component: mingw-filesystem (Show other bugs)
i686 Linux
unspecified Severity high
: ---
: ---
Assigned To: Erik van Pienbroek
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-05-19 09:38 EDT by Steve
Modified: 2013-05-20 18:50 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-05-20 18:50:54 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch to fix MinGW cmake toolchain configuration (878 bytes, patch)
2013-05-19 09:38 EDT, Steve
no flags Details | Diff
Test case (6.18 KB, application/x-bzip2)
2013-05-19 10:12 EDT, Steve
no flags Details

  None (edit)
Description Steve 2013-05-19 09:38:48 EDT
Created attachment 750043 [details]
Patch to fix MinGW cmake toolchain configuration

While building packages with MinGW, I discovered that it was searching the host's cmake configuration while cross-compiling for the Win32 target!  There are two problems.

One is that /usr/share/mingw/Toolchain-mingw{32,64}.cmake both need an extra line, to tell cmake not to search for packages in the host's cmake configuration.  Enclosed is a patch to apply in the SOURCES directory, after mingw-filesystem-97-1.fc18.src.rpm has been installed there.

The other is that there is no MinGW cmake configuration.  I've created a source RPM with the necessary information.  You can find it at https://www.box.com/s/iao568wpeuqnghfr8k29 .
Comment 1 Erik van Pienbroek 2013-05-19 09:54:43 EDT
Thanks for your contribution!

Would you also be able to provide a small testcase? (A small shell script and a CMakeLists.txt file would be sufficient) which we can use to make sure the updated behaviour is correct?

Such a testcase can then be added to our testsuite ( http://fedoraproject.org/wiki/MinGW/Testsuite ) so we can make sure no regressions happen in this area in future versions of mingw-filesystem.
Comment 2 Steve 2013-05-19 10:12:05 EDT
Created attachment 750047 [details]
Test case

All I can offer is the way I discovered the problem.  Enclosed are the two extra files needed to build phonon for MinGW.  Grab the latest phonon source RPM from the Fedora yum repos, install it, then unpack this archive to your rpmbuild directory.  Make sure you have pulseaudio-libs-devel installed too, so that the unpatched MinGW build system will accidentally find it.

You'll see that building the MinGW phonon finds PulseAudio, but then can't find any of the actual information that goes along with it, and thus fails.

Once the MinGW build system is patched, and mingw{32,64}-cmake is installed, the MinGW phonon build should succeed.
Comment 3 Steve 2013-05-19 10:14:33 EDT
Other than that, creating a testcase is kind of difficult -- you'd have to have a situation where you've got a devel package installed on the host but not in MinGW.
Comment 4 Erik van Pienbroek 2013-05-19 10:46:59 EDT
(In reply to comment #3)
> Other than that, creating a testcase is kind of difficult -- you'd have to
> have a situation where you've got a devel package installed on the host but
> not in MinGW.

These kind of situations can be enforced in our testsuite, that shouldn't be a problem. I'm taking a look at your testcase right now
Comment 5 Erik van Pienbroek 2013-05-19 11:00:41 EDT
I just tried to reproduce the issue using the mingw-phonon package you attached in comment 2, but it seems to build just fine here:

$ rpm -qa | grep pulseaudio | sort

$ rpm -qa | grep cmake

$ rpm -qa | grep mingw | grep filesystem

$ rpmbuild -ba mingw-phonon.spec
fout: Failed build dependencies:
	mingw32-kde-filesystem is needed by mingw-phonon-4.6.0-6.fc19.noarch
	mingw64-kde-filesystem is needed by mingw-phonon-4.6.0-6.fc19.noarch

$ rpmbuild -ba mingw-phonon.spec --nodeps
+ /usr/bin/cmake -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr/i686-w64-mingw32/sys-root/mingw -DCMAKE_INSTALL_LIBDIR:PATH=/usr/i686-w64-mingw32/sys-root/mingw/lib -DINCLUDE_INSTALL_DIR:PATH=/usr/i686-w64-mingw32/sys-root/mingw/include -DLIB_INSTALL_DIR:PATH=/usr/i686-w64-mingw32/sys-root/mingw/lib -DSYSCONF_INSTALL_DIR:PATH=/usr/i686-w64-mingw32/sys-root/mingw/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/i686-w64-mingw32/sys-root/mingw/share -DCMAKE_SKIP_RPATH:BOOL=ON -DBUILD_SHARED_LIBS:BOOL=ON -DCMAKE_TOOLCHAIN_FILE=/usr/share/mingw/Toolchain-mingw32.cmake -DPHONON_BUILD_TESTS:BOOL=ON -DPHONON_INSTALL_QT_EXTENSIONS_INTO_SYSTEM_QT:BOOL=ON -DHOST_PREFIX_PATH:STRING=/usr/bin -DHOST_PACKAGE_PATH:STRING=/usr/lib64/automoc4 .. ..
-- The C compiler identification is GNU 4.8.0
-- The CXX compiler identification is GNU 4.8.0
-- Check for working C compiler: /usr/bin/i686-w64-mingw32-gcc
-- Check for working C compiler: /usr/bin/i686-w64-mingw32-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/i686-w64-mingw32-g++
-- Check for working CXX compiler: /usr/bin/i686-w64-mingw32-g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- !!!!! Tests have been removed and need to be redone !!!!!
-- Building tests.
-- Looking for Q_WS_X11
-- Looking for Q_WS_X11 - not found
-- Looking for Q_WS_WIN
-- Looking for Q_WS_WIN - found
-- Looking for Q_WS_QWS
-- Looking for Q_WS_QWS - not found
-- Looking for Q_WS_MAC
-- Looking for Q_WS_MAC - not found
-- Found Qt-Version 4.8.4 (using /usr/i686-w64-mingw32/bin/qmake-qt4)
-- Found Automoc4: /usr/bin/automoc4
-- Performing Test HAVE_FPIE_SUPPORT
-- Performing Test HAVE_FPIE_SUPPORT - Failed
-- Performing Test __KDE_HAVE_W_OVERLOADED_VIRTUAL - Success
-- Performing Test __KDE_HAVE_GCC_VISIBILITY
-- Performing Test __KDE_HAVE_GCC_VISIBILITY - Success
-- Could NOT find PulseAudio
Comment 6 Steve 2013-05-19 12:26:31 EDT
With my changes reverted, and even with mingw{32,64}-kde-filesystem removed, I get this at the end:

CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
   used as include directory in directory /data/rpmbuild/BUILD/phonon-4.6.0/phonon
   used as include directory in directory /data/rpmbuild/BUILD/phonon-4.6.0/phonon
    linked by target "phonon" in directory /data/rpmbuild/BUILD/phonon-4.6.0/phonon
    linked by target "phonon" in directory /data/rpmbuild/BUILD/phonon-4.6.0/phonon

Maybe you also need to have glib2-devel, mingw32-glib2, and mingw64-glib2 installed?
Comment 7 Erik van Pienbroek 2013-05-19 12:28:00 EDT
I've already got glib2-devel, mingw32-glib2 and mingw64-glib2 installed.
Perhaps it's because I'm already on f19 (with the mingw packages from rawhide) ?
Comment 8 Steve 2013-05-19 12:40:56 EDT
Evidently so...I just did "koji build --scratch --arch-override=i386 f19 SRPMS/mingw-phonon-4.6.0-6.fc18.src.rpm" and it succeeded.

See http://koji.fedoraproject.org/koji/taskinfo?taskID=5398145 to verify the success.

I just looked at mingw-filesystem-97-3.fc19.src.rpm, and its SOURCES/Toolchain-mingw* don't have a "SET(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)".

Possible upstream bug fix to cmake, then?  I'm lost.
Comment 9 Steve 2013-05-19 12:53:07 EDT
Argh, now I'm completely lost... "koji build --scratch f18 --arch-override=i386 SRPMS/mingw-phonon-4.6.0-6.fc18.src.rpm" just succeeded!

See http://koji.fedoraproject.org/koji/taskinfo?taskID=5398279 to share in my confusion.

Did I get a bad upgrade with fedup?  I just moved from FC17 to FC18 a few weeks ago.

Yesterday I was having some other odd problems with cmake, and out of desperation, I did "yum reinstall cmake", but it didn't help.
Comment 10 Steve 2013-05-20 18:50:54 EDT
Well, that's just plain icky...I went through all the fun of re-installing my operating system, and this bug simply vanished.  I can build mingw-phonon without any problems now.

I saved my old system partition; once I get the new partition fleshed out, I'll diff them and see if I can spot where the old one went wrong.

I'll close this bug.  Sorry to waste your time.

Note You need to log in before you can comment on or make changes to this bug.