#17 Molsketch fails to build from source on Fedora 25

[Alexander Ploumistos]

Hello Hendrik,

I am trying to package Molsketch for Fedora, but I can't get the latest version to compile on F25.
The build exits with this error message:

/usr/include/qt5/QtCore/qmetatype.h:1376:33: error: invalid application of 'sizeof' to incomplete type 'QGraphicsScene'
         Q_STATIC_ASSERT_X(sizeof(T), "Type argument of Q_DECLARE_METATYPE(T*) must be fully defined");
                                 ^
/usr/include/qt5/QtCore/qglobal.h:746:66: note: in definition of macro 'Q_STATIC_ASSERT_X'
 #define Q_STATIC_ASSERT_X(Condition, Message) static_assert(bool(Condition), Message)
                                                                  ^~~~~~~~~
libmolsketch/src/CMakeFiles/molsketch_LIB.dir/build.make:644: recipe for target 'libmolsketch/src/CMakeFiles/molsketch_LIB.dir/fileio.cpp.o' failed
make[2]: *** [libmolsketch/src/CMakeFiles/molsketch_LIB.dir/fileio.cpp.o] Error 1

I believe it might have to do with some Qt5 "peculiarities":
http://doc.qt.io/qt-5/custom-types.html

I am attaching the build logs from a Mock chroot on my system and you can find my spec file here:
https://paste.fedoraproject.org/paste/tW7urB0eercUexPMR62S2Q

Please let me know if I can do anything else to help.

Best regards
Alexander Ploumistos

[Hendrik Vennekate]

Hi Alexander,

sorry for my belated response, for some reason I must have missed the sourceforge email notification (spam filter, I guess).
I'll look into it after publishing version 0.5.0, in which the build will change quite a bit. If that's possible, I would kindly ask you to try again with 0.5.0, just to be sure.

Kind regards,

Hendrik

[Alexander Ploumistos]

Sure, no worries. I'll start afresh with 0.5.0 and we'll see from there.

[Hendrik Vennekate]

Hi Alexander,
first of all -- as I missed that the last time around -- let me thank you for undertaking the effort of building binary packages for Fedora.
Now taking a quick glance at the application.log you attached, it seems that CMake did not find Qt5. It reads:

-- Found Qt4: /usr/bin/qmake-qt4 (found suitable version "4.8.7", minimum required is "4.5.0")

My apologies for that, but that statement is not quite accurate anymore -- I've been somewhat lazy in keeping Qt4 support and it probably won't build (it is quite a hassle to support the whole matrix of Qt4/5, Windows, Linux, Mac, qmake, and CMake). I'm just uploading 0.5.0 and both CMake and qmake should work; Qt5 will be required, however. Personally, I prefer using qmake (at least for now).

Sorry for that; please let me know if you need me to re-instate the Qt4 support. As I'm also making more use of newer C++11 and 14 features, I felt that transition had to come eventually (maybe I was wrong). If the problem is more that your CMake does not find your Qt5 installation, I would suggest trying qmake (Molsketch relies on the CMake scripts to find its Qt version, so I don't really have any good proposal there).

Hope that helps and kind regards,

Hendrik

[Alexander Ploumistos]

Hello Hendrik,

After a bit of trial and error, amending the spec file along the way, I got to this error:

Project MESSAGE: Using pkgconfig to find OpenBabel.
make[1]: Entering directory '/builddir/build/BUILD/Molsketch-0.5.0/obabeliface'
compiling obabeliface.cpp
make[1]: Leaving directory '/builddir/build/BUILD/Molsketch-0.5.0/obabeliface'
obabeliface.cpp: In function 'bool Molsketch::isInputFormatAvailable(OpenBabel::OBConversion, const char*)':
obabeliface.cpp:367:85: error: format not a string literal and no format arguments [-Werror=format-security]
     qInfo(("Available formats: " + outputFormats().join(", ")).toStdString().c_str());
                                                                                     ^
cc1plus: some warnings being treated as errors
make[1]: *** [Makefile:422: obabeliface.o] Error 1
make: *** [Makefile:133: sub-obabeliface-make_first-ordered] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.tbvJwb (%build)

I have attached the complete build log.
Any ideas? Am I missing a dependency perhaps or is that due to code incompatibility with the latest gcc?

Thanks
Alexander

[Hendrik Vennekate]

Hi Alexander,

that seems to be due to sloppiness on my part. In obabeliface.cpp, the argument of qInfo() is not a string literal (but, instead, a string compiled from a list of strings), which is regarded as a security risk by gcc if the -Werror=format-security option is enabled. To my surprise, I couldn't quite reproduce that, but I've replaced that line (obabeliface.cpp, 367) with

qInfo() << ("Available formats: " + outputFormats().join(", "));

which should not cause that problem. Please try downloading the updated version 0.5.0 or applying an appropriate patch to your version and let me know if that works.

Cheers,

Hendrik

[Alexander Ploumistos]

That did help and compilation failed a lot further down the road, see build.log. I have used the same spec file.
There were a lot of output, but I think the problem was during this stage:

[ 71%] Linking CXX shared library libmolsketch-qt5.so

It was followed by a lot of messages like these:

CMakeFiles/molsketch_LIB.dir/molsketch_LIB_autogen/mocs_compilation.cpp.o: In function `Molsketch::abstractRecursiveItemAction::qt_static_metacall(QObject*, QMetaObject::Call, int, void**)':
/builddir/build/BUILD/Molsketch-0.5.0/libmolsketch/molsketch_LIB_autogen/T4QKTR7IAB/moc_abstractrecursiveitemaction.cpp:63: multiple definition of `Molsketch::abstractRecursiveItemAction::qt_static_metacall(QObject*, QMetaObject::Call, int, void**)'
CMakeFiles/molsketch_LIB.dir/moc_abstractrecursiveitemaction.cpp.o:/builddir/build/BUILD/Molsketch-0.5.0/libmolsketch/moc_abstractrecursiveitemaction.cpp:63: first defined here
CMakeFiles/molsketch_LIB.dir/molsketch_LIB_autogen/mocs_compilation.cpp.o: In function `QScopedPointer<QObjectData, QScopedPointerDeleter<QObjectData> >::operator->() const':
/usr/include/qt5/QtCore/qscopedpointer.h:118: multiple definition of `Molsketch::AbstractItemAction::metaObject() const'
CMakeFiles/molsketch_LIB.dir/moc_abstractitemaction.cpp.o:/usr/include/qt5/QtCore/qscopedpointer.h:118: first defined here
CMakeFiles/molsketch_LIB.dir/molsketch_LIB_autogen/mocs_compilation.cpp.o:(.data.rel.ro+0x8c0): multiple definition of `Molsketch::AbstractItemAction::staticMetaObject'
CMakeFiles/molsketch_LIB.dir/moc_abstractitemaction.cpp.o:(.data.rel.ro+0x0): first defined here

[Hendrik Vennekate]

Sorry, for the delay -- SourceForge was apparently down the last couple of days. From looking at your build.log, it appears that you are first building using qmake and then again using CMake. Might it be that, during the linking after the CMake build, somehow this produces the duplicate definition error? It seems that the qmake build by itself is successful. On my machine, both qmake and CMake seem to work (separately, that is ;-) ).

[Alexander Ploumistos]

From looking at your build.log, it appears that you are first building using qmake and then again using CMake. Might it be that, during the linking after the CMake build, somehow this produces the duplicate definition error?

Thanks, that was my bad, I had left a " #%cmake . " commented out in the %build section which got activated.

It took a few /usr/local → /usr and /lib* → /usr/lib* substitutions and in the end I managed to get it to build.

Now I need to whip the spec file into shape and declare all the files, documentation and license.

I also found this spec file from openSUSE, which contains far more Qt5 dependencies than mine and I would like to ask another of our packagers, who knows a lot more about Qt than I do, to take a look at mine. They have also created libmolsketch and molsketch-devel subpackages, which seems a bit weird. I will need to check about these too.

There is also a policy in Fedora against bundled libraries, but as far as I can tell, libmolsketch and libobabeliface are private to molsketch, so I won't need to do anything about them, correct?

I have to be at a conference for the next three days, so I won't have much time to deal with all of the above. I will try to fix the spec file by Sunday night and take things from there.

Have a nice weekend,
Alexander

[Hendrik Vennekate]

Glad to hear that that the build is now working and thanks for the feedback.
In the qmake build, you can set the MSK_PREFIX like so:

qmake-qt5 MSK_PREFIX=/usr /path/to/molsketch/source

(the docs seem not to have been updated, but it says it during the build)
In CMake, you can set the paths like so:

cmake -D MSK_INSTALL_BINS=/usr/bin -D MSK_INSTALL_LIBS=/usr/lib64 -D MSK_INSTALL_INCLUDES=/usr/include -D MSK_INSTALL_DOCS=/usr/share/doc/molsketch /path/to/molsketch/source

Again, the docs are not up to date, but it says it during the initial cmake call.

As for OpenSuSE: While I use it, I'm not involved in the packaging, but in https://sourceforge.net/p/molsketch/bugs/12/ (Bug #12), Aliaksei Padvalski reported about building for it (not sure if he's still active, though). From my understanding, they usually package a "-devel" package with mainly the headers for development. The idea with libmolsketch was indeed (and still is) to eventually make the core of Molsketch available to others, for instance as a Calligra plugin or the like, but that will take a while, so for now I would concur, that it's really one "unit" (the binary and the lib -- call it "package", if you like ;) ).

Best wishes and have a nice weekend,

Hendrik

[Alexander Ploumistos]

Oh, I think you can close the ticket.

[Hendrik Vennekate]

Will do, thanks.