compile error resfile.o 58% through the process (qtcreator)

• Dec 16, 2016 - 13:41

Greetings!
I'm a newbie with the Musescore code, but seems I have it more or less under control. Code compiles fine from the command line, but when I try to compile/debug within QTCreator, I get this:

[ 58%] Generating ../resfile.o
'-i' is not recognized as an internal or external command,
operable program or batch file.
mscore\CMakeFiles\mscore.dir\build.make:850: recipe for target 'resfile.o' failed
CMakeFiles\Makefile2:254: recipe for target 'mscore/CMakeFiles/mscore.dir/all' failed
makefile:148: recipe for target 'all' failed
mingw32-make.exe[2]: *** [resfile.o] Error 1

sure enough this is line 850 in the build.make file, the only -i in the whole file:

num=$(CMAKE_PROGRESS_153) "Generating ../resfile.o"
cd /d C:\Users\Bix\Documents\GitHub\MuseScore\mscore\data && -i mscore.rc -o
etc...

Any insights?

Thanks!
John

Comments

• Dec 20, 2016 - 13:51

So I followed the tread in that post and modified my build.make file thus:

resfile.o: ../mscore/data/mscore.rc
@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --blue --bold --progress-dir=C:\Users\Bix\Documents\GitHub\MuseScore\build.qtc\CMakeFiles --progress-num=$(CMAKE_PROGRESS_149) "Generating ../resfile.o"
cd /d C:\Users\Bix\Documents\GitHub\MuseScore\mscore\data && C:\Qt\Tools\mingw491_32\bin\windres.exe -i mscore.rc -o C:/Users/Bix/Documents/GitHub/MuseScore/build.qtc/mscore.res
cd /d C:\Users\Bix\Documents\GitHub\MuseScore\mscore\data && C:\Qt\Tools\mingw491_32\bin\windres.exe C:/Users/Bix/Documents/GitHub/MuseScore/build.qtc/mscore.res -o C:/Users/Bix/Documents/GitHub/MuseScore/build.qtc/resfile.o

and I can compile, but still no link, same errors basically as in that post. I am trying to run 3.0 and it seems the link problem was "resolved" by using a much older version.

At least I can indeed debug inside QtCreator, so I suppose that is good enough, but it would be nice if the whole thing could be handled inside creator. Any thoughts regarding those linker errors?

Thanks!
John

Reply

• Dec 20, 2016 - 14:14

I've never even tried compiling outside of QtCreator - I only use QtCreator for compiling and debugging. I don't have any problems at all. Is it possible you have the wrong version of Qt or something like that? I just got my current build system up about a month ago, so I'm probably using current tools.

Reply

• Dec 20, 2016 - 14:44

Im using current tools, used the version of qt from the online instructions, though qtcreator is a newer version than shown, so some of the screenshots for the install were not exactly the same. Are you using latest cmake or an older version? I was unable to find older releases and it has been a while since I used it, and not on this machine

Reply

• Dec 20, 2016 - 16:54

First off, the rapid response here is truly wonderful! Been a while since I experienced this level of commitment! Thinking I might have landed in a nice place :)

So,
4.2 has different UI screens for sure than those instructions, which I followed. Should I be using THE VERY LATEST QT? because I installed Qt to match the screens, iow, I installed 5.6, creator is 4.2, and musescore is 3.0

Tempted to start from scratch on another machine, if I can get confirmation of exact versions of each bit that has worked for others. BTW, windows 8 if that makes a difference.

Reply

• Dec 20, 2016 - 18:23

more stuff to go through, will have a fresh look in the morning. Again thanks for the help. I can indeed debug if not compile in creator and that is halfway there. I have a good friend, a piano player, composer, and teacher, who loves this software and asked me if I can add some enhancements to aid in his pedagogy and compositions. He's actually on a Linux distro, so I someday hope to make a real pull request that gets added to the official release!

Reply

• Dec 20, 2016 - 20:05

If you want, you can already post some of his requests into the feature request forum or even the Issue tracker if they're not in there already. You just might get lucky and find another developer willing to help out; if not, then at least it helps keeping track and possibly avoid double work.

Reply

• Jan 10, 2017 - 09:17

Sorry if I chime in maybe too late. The generation of resfile.o is coded here:
lines 405-406 of mscore/CMakeLists.txt
where QT_WRC_EXECUTABLE and QT_WINE_EXECUTABLE are defined in build/mingw32.mingw.cmake as build/wrc.bat and build/wine.bat.
build/mingw32.cmake lines 31-32
These .bat files contains the instruction "windres" assuming Mingw bin folder is in the PATH (in the "wine.bat" case it also skips the first argument so that the string "/home/ws/.wine/drive_c/MingW/bin/windres.exe" is completely ignored).

Apparently in the case of this topic the QT_WRC_EXECUTABLE and QT_WINE_EXECUTABLE are not properly set (from the analysis of the make file, they are empty). Could it be a problem of the "-DCMAKE_TOOLCHAIN_FILE=build/mingw32.mingw.cmake" parameter or maybe a caching problem (note that "it leads to a warning about being unused on subsequent times" because after the first time the values are read from the cmake cache instead of mingw32.mingw.cmake)?

Reply

• Jan 10, 2017 - 11:04

Hmm, you point at the mscore/CMakeLists.txt and build/mingw32.mingw.cmake files of the master branch, but the problem happens only with the 2.1 branch, at least for me.
These files don't look fundamentally different there though:

https://github.com/musescore/MuseScore/blob/2.1/mscore/CMakeLists.txt#L…
https://github.com/musescore/MuseScore/blob/2.1/build/mingw32.mingw.cma…

so I guess the problem got to be somewhere else. I don't think it is cache, as I've deleted the build.qtc and win32install directories and also the CMakeLists.txt.user file, restarted QtCreatore, with a .bat that sets everything for Qt-5.4, configured it from scratch and still had the issue

Reply

• Mar 1, 2017 - 16:57

@ABL, I've ran into the exact same problem as described when Building MuseScore 2.1 on a fresh git checkout (in a seperate folder from my master checkout, so I loaded as a fresh separate project in QtCreator). Here is the errors in compile output (the failure of resfile.o happens right after built libmscore):

[ 51%] Built target libmscore
[ 51%] Generating ../resfile.o
[ 51%] Generating qrc_musescorefonts-Bravura.cpp
[ 51%] Generating qrc_musescorefonts-MuseJazz.cpp
'-i' is not recognized as an internal or external command,
operable program or batch file.
mscore\CMakeFiles\mscore.dir\build.make:839: recipe for target 'resfile.o' failed
mingw32-make.exe[2]: *** [resfile.o] Error 1
mingw32-make.exe[2]: *** Waiting for unfinished jobs....
Qt: Untested Windows version 10.0 detected!

Attached are the files you requested Jojo to upload.

I'm going to try the workaround described in https://musescore.org/en/node/48891#comment-370551

Attachment Size
CMakeLists.txt.user_.txt 244.03 KB
CMakeCache.txt 39.4 KB
build.make_.txt 628.01 KB

Reply

• Mar 1, 2017 - 17:05

Assuming you are currently following the compile instructions correctly, I found that this results from leftover cached information from a previous *incorrect* build. In particular, even though you might currently be specifying the CMAKE_TOOLCHAIN_FILE correctly, you must have done an initial cmake run without it, and it remembers that and is refusing to honor the one you specify, and therefore isn't finding the necessary tool at all. After a bunch of attempts to clean things up directly, I finally just deleted the whole build.qtc folder and kicked off a new build, which worked. If you do this, you don't need to mess with editing the toolchain file or the build script or anything else. The "/home/ws" but is a red herring - even though it's there in the file, it's harmless.

*Except*, I also noted that QtCreator was "correcting" my CMAKE_BUILD_TYPE from DEBUG as I typed it to Debug, and as a result, I wasn't actually getting debug info. I had to manually add that (just as you do for CMAKE_TOOLCHAIN_FILE) and then do a make clean and rebuild, then I was up and running.

Reply

• Mar 2, 2017 - 17:36

@ericfontainejazz :
in your CMakelist.txt.user and CMakeCache the CMAKE_TOOLCHAIN_FILE variable pointing to build/mingw32.mingw.cmake is missing, therefore the variables QT_WRC_EXECUTABLE and QT_WINE_EXECUTABLE are not defined and in build.make instead of build/wrc.bat and build/wine.bat for the resfile.o option only empty strings are present.
Have you used the following arguments in a fresh build?
-DCMAKE_BUILD_TYPE=DEBUG -DCMAKE_TOOLCHAIN_FILE=build/mingw32.mingw.cmake -DCMAKE_INSTALL_PREFIX=../win32install
In the CMakelist.txt.user there is only the CMAKE_BUILD_TYPE option.
I think there is maybe an error in the above arguments: CMAKE_TOOLCHAIN_FILE should be defined relative to the folder in which cmake is launched. In the Makefile.mingw it is defined as (note the additional "../")
-DCMAKE_TOOLCHAIN_FILE=../build/mingw32.mingw.cmake

Reply

• Mar 3, 2017 - 16:33

What Marc pointed out here seems to have been true:

even though you might currently be specifying the CMAKE_TOOLCHAIN_FILE correctly, you must have done an initial cmake run without it, and it remembers that and is refusing to honor the one you specify, and therefore isn't finding the necessary tool at all

After I defined CMAKE_TOOLCHAIN_FILE correctly I pressed "Apply Configuration Changes" button and rebuilt, and that seemed to have done the trick.

But I'm not sure where I went wrong because I believed that I followed https://musescore.org/en/developers-handbook/compilation/compile-instru… to the letter (unless maybe I didn't). In particular I notice I had set CMAKE_TOOLCHAIN_FILE via Manage Kits -> selecting the Qt 5.4.2 version -> and selecting "Change" button for CMake Configuration and clicking OK twice. But I am noticing now that changing it to something bogus doesn't result in the Build Setting's window to reflect what I changed, and I notice there is a warning message "CMake configuration set by the kit was overridden in the project" and that the CMAKE_TOOLCHAIN_FILE variable doesn't reflect the bogus change. So maybe there was a change in qtcreator's ui, or maybe I actually didn't follow those instructions to the 't'.

Anyway it is working now that I modified CMAKE_TOOLCHAIN_FILE in the Build Settings window. I don't know if the handbook needs to be updated somehow, but I guess if I should try checking out musescore to another folder and trying from scratch.

Reply

• Mar 3, 2017 - 17:53

For whatever reason, this particular settings gets cached the first time it is specified and gets ignored after that. The compile instructions mention that fact specifically. So it is very important to get this right the first time you run cmake in any given project. Most likely QtCreator kicked off a cmake run before you got around to adding that option. With older versions of QtCreator, this wouldn't likely happen as you were forced to deal with a dialog specifying cmake options before it would ever think about trying to run cmake. Now, depending on how you do things from within QtCreator, it seems it may try an initial run before you specify these options. I'm not sufficiently expert on QtCreator to understand why this might be happening or how to prevent it.

Reply

Do you still have an unanswered question? Please log in first to post your question.