Unable to link mtest in Windows QT 5.6 QtCreator 4.0+ unless I disabled OMR
I couldn't figure out why the linking step would fail. poppler code had all these errors about not being able to find setAttribute for QDomElement http://doc.qt.io/qt-5/qdomelement.html ...which sounds like somehow the windows build code is not including QtXML (or something else?) in the linking step. I couldn't quite figure out how to debug an mtest other than by disabling OMR in the toplevel CMakeLists. Just seeing if anyone else has experienced this or knows the solution.
Comments
I found the same both under Windows and when running cross-compiled tests with Wine under Linux.
It is a problem of linking order in the dependencies; I don't know why it doesn't appear also under Linux. Poppler seems to depend on QtXML, but Qt libraries are included before Poppler in mtest/cmake.inc.
If ${QT_LIBRARIES} is added after poppler here , this part of the compilation goes ok, i.e:
target_link_libraries(${TARGET} omr poppler ${QT_LIBRARIES})However, there is also a problem with Zerberus tests when running the tests under Windows since the result of
size()instruction is not anunsigned longunder 32bit Windows, for example here and in other Zerberus tests.I locally solved it by using
quintptrinstead ofunsigned long(see //doc.qt.io/qt-5/qtglobal.html#quintptr-typedef ), but I don't know if it is the correct type to be used.There is also a rounding problem in the fourth decimal digit in one of the tests for one articulation (i.e. under Windows it is different than under Linux), but maybe the recent change to articulations solved it (I didn't check Windows tests last week).
Ciao,
ABL
In reply to I found the same both under by ABL
thanks for that info! If a simple reordering to the cmake.inc fixes that linking, then can you or someone submit a PR for that?
Regarding size(), I haven't looked closely into that code, but I do know that there is a special type of unsigned int called size_t which is what is supposed to be used to hold the result of size() operation. Is size_t the answer here?
EDIT: oh wait...I'm thinking that size_t is for sizeof() operation, which is something differnet.
Anyway, my vote would be to use the qt construct, since qt goes to great length to make their things as cross-platform as possible.
In reply to thanks for that info! If a by ericfontainejazz
Or maybe simply using
unsigned intinstead ofunsigned long.In reply to Or maybe simply using by ABL
Int and Long are machine-specific constructs. I would use quint32 or quint64, since those are guaranteed to be a specific size across all systems.
In reply to Int and Long are by ericfontainejazz
wait...I finally looked up zones, and I see it is a std::list. According the c++ std lib specs, the size() operation returns a "size_type", and therefore the QCOMPARE should use the size_type for the type cast. http://en.cppreference.com/w/cpp/container/list/size
Sorry I went back and forth a few times...
In reply to wait...I finally looked up by ericfontainejazz
See https://github.com/musescore/MuseScore/pull/2865
It compiles and run on Linux and Mac (and windows I guess)
In reply to See by [DELETED] 5
THANKS. Compiled mscore on my windows machine without having to disable OMR.
Although there was something very strange I had to do, which I can't explain because I didn't get this error two days ago: https://musescore.org/en/node/136881