Plugin embedding - using xembed protocol qt5 crash on linux

[Rikislav]

Linux Ubuntu 16.04 - QT 5.9.1
When using VesTige with the xembed protocol option lmms crashes with this message:

/lmms: symbol lookup error: /plugins/libvstbase.so: undefined symbol: _ZN18QX11EmbedContainerC1EP7QWidget

[PhysSong]

Are you using AppImage, or manually compiled version?
Tagging @lukas-w.

[Rikislav]

I'm compiling directly, through QtCreator. Sending a screenshot

[PhysSong]

@Rikislav Could you change makefile generator to Unix Makefiles or similar?

[Z3R0C]

i get the same crashes (same message) with some vst's...if i'm switch to "no embed" option, i get a black empty window and a load average allround 25-30. it's like a freeze. all this testet vst's (zampler/trickster, a.n.a, dune2, nexus2) was working with RC4.

ubuntu 17.10, qt 5.9.1, compiled with GCC

ps: all this vst's are working stable inside the Carla Plugin. it's a real LMMS-bug

[Rikislav]

Ok, I changed compiler to Unix Makefile, and in LMMS selected the XEmbed protocol, but there is no noticeable change when using a vst dll:

Starting using X11Embed protocol.
RemotePlugin::DebugMessage: inputs: 0 output: 8
RemotePlugin::DebugMessage: creating editor
RemotePlugin::DebugMessage: editor successfully created
/home/riki/git_from/lmms_debug/lmms: symbol lookup error: /home/riki/git_from/lmms_debug/plugins/libvstbase.so: undefined symbol: _ZN18QX11EmbedContainerC1EP7QWidget
/home/riki/git_from/lmms_debug/lmms exited with code 127

The RemoteVstPlugin.exe.so and wineserver remain among running processes and eventually lead to a general crash

Sorry for such a delay in answering, busy period.

[qnebra]

I have same issue, but with my own compilled version. VST plugins under official RC5 version works fine.

[PhysSong]

@lukas-w I don't know if this is related, but should this be IF(WANT_QT5 AND LMMS_BUILD_LINUX)?

lmms/src/3rdparty/CMakeLists.txt

Line 4 in 96c5f05

IF(QT5 AND LMMS_BUILD_LINUX)

[qnebra]

1.2-rc5.1 - VST works fine
1.2-rc5.219 (latest master) - crash

[lukas-w]

@PhysSong WANT_QT5 implies QT5:

lmms/CMakeLists.txt

Lines 136 to 137 in 96c5f05

	IF(WANT_QT5)
	SET(QT5 TRUE)

@Rikislav @qnebra I'm guessing you're both on master. This appears to be a regression from #4041 (or rather a merge conflict between #4041 and #3786). #4041 removed Qt4 support and with it the WANT_QT5 and QT5 variables on master, while the checks for those variables for qx11embedcontainer remained:

lmms/src/3rdparty/CMakeLists.txt

Lines 4 to 7 in ab2cc42

	IF(QT5 AND LMMS_BUILD_LINUX)
	set(BUILD_SHARED_LIBS OFF)
	add_subdirectory(qt5-x11embed)
	ENDIF()

lmms/plugins/vst_base/CMakeLists.txt

Lines 29 to 31 in ab2cc42

	IF(LMMS_BUILD_LINUX AND WANT_QT5)
	TARGET_LINK_LIBRARIES(vstbase qx11embedcontainer)
	ENDIF()

[qnebra]

@lukas-w This have a lot of sense.

[tresf]

@lukas-w thanks for figuring this out. I'm on it.

[tresf]

@Rikislav can you pull down the latest changes and report your findings? Should be patched via 5c3c052.

[Rikislav]

Ok, I did as a fresh git clone then a submodule init and update recursive but the git doesn't get all submodules right. I recall someone has already figured out this submodule issue, can you just point me out where I can find the fix (sorry, I have little time)?

Submodule path 'src/3rdparty/weakjack/weakjack': checked out 'cbb05c52561d921885ad6651af6c8dd9f514dc9a'
Unable to checkout 'aad301a6ebbab769620b0bb0e77713c4659117a6' in submodule path 'plugins/Xpressive/exprtk'

And, of course in CMake

fatal: reference is not a tree: aad301a6ebbab769620b0bb0e77713c4659117a6
Unable to checkout 'aad301a6ebbab769620b0bb0e77713c4659117a6' in submodule path 'plugins/Xpressive/exprtk'

--   Retrying plugins/Xpressive/exprtk using 'remote add submodulefix' (attempt 1 of 2)...
--   Adding remote submodulefix to plugins/Xpressive/exprtk
--   Fetching plugins/Xpressive/exprtk
--   Fetching plugins/Xpressive/exprtk @ --depth 100
fatal: reference is not a tree: aad301a6ebbab769620b0bb0e77713c4659117a6
Unable to checkout 'aad301a6ebbab769620b0bb0e77713c4659117a6' in submodule path 'plugins/Xpressive/exprtk'

[tresf]

@Rikislav sorry, we're waiting on the upstream to comment on the broken exprtk plugin, or more specifically why he deleted the commit LMMS was working from. See #4089

You can disable it locally for now by commenting out the Xpressive plugin in plugins/CMakeLists.txt, sorry for the inconvenience.

[Rikislav]

Hmmm. I did as suggested, commented out xpressive in the plugins/CMakeLists.txt, but to ignore the expressive plugin had to also add the string which bypasses the looking for its submodule in CheckSubmodules.cmake:

SET(SKIP_SUBMODULES "exprtk")

this issue was solved, but now there is another problem which didn't occur before, and it still seem to be related to the submodule:

CMake Error at src/3rdparty/qt5-x11embed/CMakeLists.txt:9 (find_package):
  By not providing "FindXCB.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "XCB", but
  CMake did not find one.

  Could not find a package configuration file provided by "XCB" with any of
  the following names:

    XCBConfig.cmake
    xcb-config.cmake

  Add the installation prefix of "XCB" to CMAKE_PREFIX_PATH or set "XCB_DIR"
  to a directory containing one of the above files.  If "XCB" provides a
  separate development package or SDK, be sure it has been installed.

[qnebra]

@tresf In my case commit:

5c3c052

fix issue.

[Rikislav]

@qnebra, @tresf the current (last) pull I use is the one patched to 5c3c052 :

/lmms$ git log
commit 5c3c052712f751048ca89c7051422da7f4001072
Author: tresf <tres.finocchiaro@gmail.com>
Date:   Tue Jan 2 09:53:54 2018 -0500

    Remove QT5 flags
    Fix a regression caused by #4041, closes #4077

[Umcaruje]

@Rikislav do you have these packages installed: libqt5x11extras5-dev qtbase5-private-dev libxcb-util0-dev libxcb-keysyms1-dev

[Rikislav]

@Umcaruje checked out, yes, I do, tried cmake again in case:

[lukas-w]

@Rikislav Run sudo apt-get install extra-cmake-modules or git submodule update --init --recursive. Either way should work.

[Rikislav]

I did both and it works now:
this time I used the submodule update --init option. Before I did
git submodule init and then did git submodule update --recursive. Are they different?

As for the extra-cmake-modules, they were missing!!!

Thank you very much for the patience, but it seems to me there really are too many things to be accounted for to make things work (I refer to the whole compiling requirements, not specifically to LMMS). If I had to reconfigure a linux machine to track all this I'd become mad, the occasional user forgets all!!

[lukas-w]

git submodule init and then did git submodule update --recursive. Are they different?

No, they're equivalent.

As for the extra-cmake-modules, they were missing!!!

They aren't actually needed as they are provided via submodules. This may be an issue with @tresf's submodule-fetching CMake script, maybe it doesn't fetch recursively?

[lukas-w]

I'm assuming 5c3c052 fixed the issue for you as well, @Rikislav. Closing.

[tresf]

Would it be possible to instead of using a particular revision of exprtk module to always use the tip of the master?

@ArashPartow thanks kindly for chiming in with a reply. In our build system, we could coerce this, but no, git submodules do not directly permit this. Is there a particular reason why the history was erased? This is generally uncommon for a master branch and it also leaves a bit of ambiguity as to what occurred for a particular update.

Worse, it takes reliable builds completely out of our hands as we wouldn't know if a breaking change existed until after our build system broke. It's not something I would encourage or want.

For now, our code pulls from my fork which has the history restored . This fork is only around until we understand if there's a viable and reliable way to use a submodule against upstream. 👍

[tresf]

@ArashPartow ok, understood you have a uniquely large file to merge there so I'm sure it was warranted. So is it safe to assume that all previous commits are encompassed inside that? If so, we can bump the version in #4089 and we'll be in good shape again. 👍