Windows 64 compile
Ciao.
After some struggle, I finally managed to compile a Windows 64bit binary distribution of MuseScore.
You can find the compiled binary ("release" compile of commit 06153cf98f ) here (7zip archive, roughly 42MB) for testing:
https://docs.google.com/file/d/0BxjayMZiuupOSVM1RXJRajNsY00/edit?usp=sh…
I used Qt5.1.1 and MinGW 4.8.1(rev5) from MinGW-builds.
I used the Jack and libsndfile 64bit binaries from the respective sites.
I downloaded 64bit libvorbis and libogg from http://sourceforge.net/projects/mingw-w64/files/External%20binary%20pac…
I downloaded 64bit portaudio from https://github.com/adfernandes/precompiled-portaudio-windows
I ran into one main problem: the precompiled header was crashing cc1plus.exe. I thus prevented the generation of all.h.gch and the compile worked (after some other little modifications), even if taking a LOOOONG time.
If you are interested, I can post all the steps and modifications I performed.
Ciao,
ABL
Comments
Always interesting to have the full procedure, but I don't really see the point of doing a 64bit build of MuseScore on Windows. Any reason why you did it?
In reply to Always interesting to have by [DELETED] 5
Actually, I did it just for fun, to verify if a 64bit compilation of MuseScore was possible under Windows :-)
I started trying to obtain a 32bit compilation of MuseScore under Linux 64bit, following #20743: [Linux] Error when launching a nightly build: binary file: it was working up to the linking point of mscore, since I could not figure out how to tell cmake or pkgconfig to use the 32bit ogg and vorbis libraries instead of the 64bit ones. I then noticed in CMakeLists.txt that in Windows the way these dependencies are set is different, so I tried the 64bit compilation in Windows to learn how things change in 32bit and 64bit compilations.
One possible answer to the benefit of a 64bit compiled binary instead of the 32bit one is for example, as already pointed out by someone else in the developer mailing list, the ability to load really heavy soundfonts (e.g. sfz files). The 32bit version does not allow to simultaneously load two copies of the Salamander Grand Piano sfz, while you can see in the attachment that I was able to simultaneously load even three copies of this sfz in the 64bit version.
By the way, other than this possible point, also I do not see the point in doing a 64bit compilation when the 32bit is working fine.
As a final point, I noticed that when you delete the sfz file from the synthesizer, the memory occupied by the soundfont samples does not seem to be freed. I don't know if this should be said in the issue tracker, since the Zerberus sfz loader/player is still highly experimental, for what I understood.
I don't think I will have time to re-check and write down all the passages I performed for the win64 compilation before the weekend, but expect something during next week.
Ciao,
ABL
In reply to Just for fun :-) by ABL
Since you are into it, there is something I want to investigate for a long time. Having MuseScore linked with Qt on Windows statically. I think it would drastically reduce the size of the MuseScore install. If you feel like it :)
In reply to Since you are into it, there by [DELETED] 5
If I understand correctly, a static build of MuseScore would require a static build of Qt, right?
I found this pre-compiled static package: http://sourceforge.net/projects/qtcnbuild/files/Qt5.1.1/Mingw48/
but, for example, QtWebkit is not present, as stated in the page of the compilation scripts for the MinGW-builds Qt: https://github.com/Alexpux/Qt-builds
"For now Qt5 static build has many restrictions and it can't be build with Webkit, ANGLE and ICU."
Moreover, perhaps there could be a problem for qml plugins:
https://bugreports.qt-project.org/browse/QTBUG-28357
However, next week I will try to see how far I can go with the static build.
In reply to If I understand correctly, a by ABL
I believe static Qt libraries are available as part of the Qt standard installation in C:\Qt\5.1.1\mingw48_32\lib on my system. Qmlplugins are indeed a problem and their dll should probably stay dynamic to start with.