Compilation issues on Linux/CMake with Musescore 2.1 zip archive

• Oct 2, 2017 - 13:37

I encountered several compilation issues for Musescore 2.1 zip archive on Linux Fedore 25 using cmake.

I am trying to make a more recent RPM package on Fedora copr.

I tested my build and it looks ok.

Setup:

  • compilation was performed in a build directory
  • LAM was disabled (as in Fedora spec)
  • prefix is /usr/local
  • other options as default

Comments

• Oct 2, 2017 - 13:38

0) make or cmake ???

Manual don't mention cmake but make. Why ???

1) Issue when lame is off in ccmake: we have to clear LAME_XXX variables else it complains these variables are unset.

2) all.h

Scanning dependencies of target manpages
[ 0%] Generating mscore.1.gz
Man pages have been compressed ready for installation.
Creating symlink alias for man pages.
Symlink alias: musescore.1.gz -> mscore.1.gz
[ 0%] Built target manpages
Scanning dependencies of target qtsingleapp_autogen
make[2]: *** No rule to make target 'all.h', needed by 'thirdparty/singleapp/src/CMakeFiles/qtsingleapp_autogen'. Stop.
CMakeFiles/Makefile2:8789: recipe for target 'thirdparty/singleapp/src/CMakeFiles/qtsingleapp_autogen.dir/all' failed
make[1]: *** [thirdparty/singleapp/src/CMakeFiles/qtsingleapp_autogen.dir/all] Error 2
Makefile:151: recipe for target 'all' failed
make: *** [all] Error 2

I copied manually all.h from source to continue

3) Then g++ complains about -fPIC due to Qt setup

(unfortunately I lost the error message)

I added it to compile all.h

/usr/lib64/ccache/c++ -fPIC -x c++-header -g -I/usr/include/qt5/ ... -o all.h.gch all.h

4) MP3 code issue (LAM is disabled)

cc1plus: warning: /home/scratch/sources/MuseScore-2.1-build/all.h.gch: created and used with differing settings of '-maccumulate-outgoing-args'
[ 83%] Linking CXX executable mscore
^[O3S^[O3SCMakeFiles/mscore.dir/loginmanager.cpp.o: In function Ms::LoginManager::onGetMediaUrlRequestReady(QByteArray)':
/home/scratch/sources/MuseScore-2.1/mscore/loginmanager.cpp:406: undefined reference toMs::MuseScore::saveMp3(Ms::Score*, QString const&)'
CMakeFiles/mscore.dir/uploadscoredialog.cpp.o: In function Ms::UploadScoreDialog::showOrHideUploadAudio()':
/home/scratch/sources/MuseScore-2.1/mscore/uploadscoredialog.cpp:196: undefined reference toMs::MuseScore::canSaveMp3()'
collect2: error: ld returned 1 exit status
mscore/CMakeFiles/mscore.dir/build.make:5885: recipe for target 'mscore/mscore' failed
make[2]: *** [mscore/mscore] Error 1
CMakeFiles/Makefile2:324: recipe for target 'mscore/CMakeFiles/mscore.dir/all' failed
make[1]: *** [mscore/CMakeFiles/mscore.dir/all] Error 2
Makefile:151: recipe for target 'all' failed
make: *** [all] Error 2

I fixed theses 2 methods
- void UploadScoreDialog::showOrHideUploadAudio()
- void LoginManager::onGetMediaUrlRequestReady(QByteArray ba)

5) At install

-- Up-to-date: /usr/local/stow/MuseScore-2.1/share/mscore-2.1/wallpaper/paper5.png
CMake Error at share/locale/cmake_install.cmake:36 (file):
file INSTALL cannot find
"/home/scratch/sources/MuseScore-2.1/share/locale/mscore_af.qm".
Call Stack (most recent call first):
share/cmake_install.cmake:43 (include)
cmake_install.cmake:57 (include)
Makefile:73: recipe for target 'install' failed
make: *** [install] Error 1

These files are not generated ???

Reply

• Oct 2, 2017 - 14:13

> the qm files are generated on 'make lrelease'
Ok it fixes the installation, I missed it

> Why not taking the sources from github?
I got stable source from https://musescore.org/fr/download/musescore.tar.bz2
Same content that on github
It don't make sense for packaging to git clone

> Also check the developers' handbook.
https://musescore.org/en/developers-handbook/compilation/compile-instru…

make script is doing roughly the same things that what I did

It is broken if we disable LAM

> MuseScore 2.1 needs Qt 5.4
Fedora 25 is shipped with Qt 5.7, I don't believe it is an issue.

Anyway other issues are probably due to issues in CMakelist or code.

Version 2.0 compiled fine.

I can't provide a RPM package until Muscore compile without hacks.

Reply

• Oct 2, 2017 - 14:18

Qt 5.7 is a issue. master needs 5.8 or later, 2.x needs 5.4, the last version to supply Web Engine (or some such), needed for the online center. This is documented in several places, at least for Mac and Windows.
The LAME issue got fixed later, in 2.2, check #201146: MuseScore 2.1 fails to build with BUILD_LAME=FALSE, git cherry-pick 0b82c14e8c

Reg. make lrelease see also https://musescore.org/en/developers-handbook/compilation/compile-instru…

Reply

• Oct 3, 2017 - 12:11

It is Qt5WebKit which was removed in Qt 5.6 core, but it is shipped as a third party in Fedora. So it is not a problem.

I believe there is still an issue for LAME in main CMakelists.txt, a fix is:

@@ -644,9 +644,12 @@
 include_directories(
    ${OGG_INCDIR}
    ${VORBIS_INCDIR}
    ${SNDFILE_INCDIR}
-   ${LAME_INCLUDE_DIR}
 )

+IF (BUILD_LAME)
+   include_directories(${LAME_INCLUDE_DIR})
+endif (BUILD_LAME)
+
 if (USE_SYSTEM_FREETYPE)
       include_directories(${FREETYPE_INCLUDE_DIRS})
 else (USE_SYSTEM_FREETYPE)

Remaining problem is all.h, I tried several time using make release, it fails for some reasons. I could not figure out what is wrong in CMakelist. I have to run make release twice. (I am using CMake 3.9.1) It seems ADD_CUSTOM_TARGET(mops1 DEPENDS ${PROJECT_BINARY_DIR}/all.h) doesn't work as expected.

...
Scanning dependencies of target manpages
make[3]: Leaving directory '/home/scratch/sources/MuseScore/MuseScore/build.release'
make[3]: Entering directory '/home/scratch/sources/MuseScore/MuseScore/build.release'
[  0%] Generating mscore.1.gz
Man pages have been compressed ready for installation.
Creating symlink alias for man pages.
Symlink alias: musescore.1.gz -> mscore.1.gz
make[3]: Leaving directory '/home/scratch/sources/MuseScore/MuseScore/build.release'
[  0%] Built target manpages
make[3]: Entering directory '/home/scratch/sources/MuseScore/MuseScore/build.release'
Scanning dependencies of target ofqf_autogen
make[3]: Leaving directory '/home/scratch/sources/MuseScore/MuseScore/build.release'
make[3]: Entering directory '/home/scratch/sources/MuseScore/MuseScore/build.release'
make[3]: *** No rule to make target 'all.h', needed by 'thirdparty/ofqf/CMakeFiles/ofqf_autogen'.  Stop.
make[3]: Leaving directory '/home/scratch/sources/MuseScore/MuseScore/build.release'
CMakeFiles/Makefile2:8476: recipe for target 'thirdparty/ofqf/CMakeFiles/ofqf_autogen.dir/all' failed
make[2]: *** [thirdparty/ofqf/CMakeFiles/ofqf_autogen.dir/all] Error 2
make[2]: Leaving directory '/home/scratch/sources/MuseScore/MuseScore/build.release'
Makefile:151: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory '/home/scratch/sources/MuseScore/MuseScore/build.release'
Makefile:50: recipe for target 'release' failed
make: *** [release] Error 2

Reply

• Oct 3, 2017 - 12:38

Yes, QtWebKit is what I meant. Still Qt-5.7 may have other issues, still the recommendation would be to use Qt 5.4, like for the other platforms, Windows and Mac.

That CMakefile.txt change looks reasonable but might not be needed, if LAME_INCLUDE_DIR were not set at all, and it shouldn't be if nither the include dir nor the library is found on your system (by build/FindLame.cmake)

I've upgraded from CMake 3.8 to 4.9.3 on Windows and it still works, but with a new warning:

CMake Deprecation Warning at CMakeLists.txt:42 (cmake_policy):
The OLD behavior for policy CMP0020 will be removed from a future version
of CMake.

The cmake-policies(7) manual explains that the OLD behaviors of all
policies are deprecated and that a policy should be set to OLD only under
specific short-term circumstances. Projects should be ported to the NEW
behavior and not rely on setting a policy to OLD.

Reply

• Feb 4, 2019 - 17:27

After a year and some versions, while building MS from scratch (new machine, new OS version, ...), I find that point 4) above (or a variant of it) is still pending in file mscore/network/loginmanager.cpp:

[ 40%] Linking CXX executable mscore
CMakeFiles/mscore.dir/network/loginmanager.cpp.o: In function Ms::ApiRequestBuilder::build() const:
[project_source_dir]/mscore/network/loginmanager.cpp:863: undefined reference to Ms::ApiInfo::clientIdHeader
[project_source_dir]/mscore/network/loginmanager.cpp:864: undefined reference to Ms::ApiInfo::apiKeyHeader
CMakeFiles/mscore.dir/network/loginmanager.cpp.o: In function Ms::ApiWebEngineRequestInterceptor::interceptRequest(QWebEngineUrlRequestInfo&):
[project_source_dir]/mscore/network/loginmanager.cpp:881: undefined reference to Ms::ApiInfo::clientIdHeader
[project_source_dir]/mscore/network/loginmanager.cpp:882: undefined reference to Ms::ApiInfo::apiKeyHeader
clang: error: linker command failed with exit code 1 (use -v to see invocation)

System: Linux Mint 18.3, Qt 9.0, sources git-cloned this morning.

Notes (if they are relevant):
1 - in order to avoid missing header errors, I had to turn off BUILD_PULSEAUDIO and BUILD_PORTMIDI.
2 - There are 140,000 (yes 140,000, it is not a type) warnings, mostly about overriding virtual functions: something need tweaking?

Reply

• Feb 4, 2019 - 23:29

Yes, "Qt 9.0" was actually Qt 5.9.0, sorry (I tend to consider "5." implied... ;) ).

Thanks for reviewing this issue and for your suggestion. I have to say that I did not understand what the Qt version (or the presence of Qt WebEngine) may have to do with locating a Ms:: own Ms::ApiInfo static member variable but, as I have lost the "feeling" for MS source code long ago, I tried your suggestion, using Qt 5.12.1 (different build directory, so there was no left-over from the previous attempt with Qt 5.9.0).

But, in fact, using Qt 5.12.1 makes no difference at all and the same errors quoted above remain.

Any other idea?

Reply

• Feb 5, 2019 - 09:32

Yes, I installed Qt WebEngine of Qt 5.12.1. In fact, I installed everything of Qt 5.1.2.1, except: Android ARM (64 and V7), sources, Qt Script and Qt Debug Info Files.

However, I still fail to understand why this could be relevant. The errors refer to 2 (static) member variables of the MuseScore own Ms::ApiInfo class which the linker is unable to locate.

Note that the mscore/network/loginmanager.cpp source file is compiled into the relevant /[build_dir]/mscore/CMakeFiles/mscore.dir/network/loginmanager.cpp.o object module, so all resolutions required at compile time are working; the problem is with the linker and with the Ms::ApiInfo class.

Then, of course, I may miss somethig obvious...

Reply

• Feb 5, 2019 - 10:17

This is related to my latest PR on login mechanism updating, and the code seems to be a bit incorrect here. The missing variables are constexpr static members of ApiInfo class (see the code), and compliers seem to inline them usually which avoids linkage errors. However before C++17 the standard doesn't require this to work so, and requires a definition of such variables be present at namespace scope.

So in order to resolve this try to put definitions of these variables in loginmanager.cpp, something like

constexpr const char* ApiInfo::clientIdHeader;
constexpr const char* ApiInfo::apiKeyHeader;

If it works, it would probably be good to put these changes into mainline MuseScore code.

Reply

• Feb 5, 2019 - 17:50

Eventually the solution was replacing clang as a C++ compiler with g++.

As this is a (relatively) recently configured machine I mostly used for other purposes with a recently installed OS and Qt, I didn't notice (well, I did notice, but I didn't care) it defaulted to using clang; after switching to g++ and rebuilding MuseScore from scratch, the source compiled correctly; in addition the 90,000+ warning messages are now reduced to 8, which is reasonable.

Perhaps, it might be useful to someone else too...

Reply

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