How to deploy in linux? about dfhack-qt HOT 18 CLOSED

I did not try that yet. I think the easiest way to distribute the plugins for Linux would be to compile it with old enough libraries and only distribute the .plugin.so files and telling the users to download Qt from their distribution repository. Application built with older Qt 5 versions should work with newer shared libraries. Using the distribution libraries and plugins also have the advantage of providing a better desktop integration.

There is another point about deployment I would like to discuss. In your repository, you keep your own fork of the qapplication. The goal of this plugin is to let multiple plugins use Qt widgets (otherwise you could simply manage the Qt event loop from your own plugin). It is okay for now since you are the only one making plugins with it, but if others start using it and everyone use their own fork of qapplication, it will be a mess. So I think I should start to distribute the plugin myself and you should use the upstream version. I started to write some cmake changes that should make it easier to keep your plugins in a different repository than the qapplication one.

To make this work, we need to agree on how to distribute the plugins and Qt versions. For Linux, if we use the method I proposed (and if it works), Ubuntu Trusty's Qt 5.2 or Xenial's Qt 5.5 could make good target (trusty may not be necessary for something new like this). For Windows, if we want to support XP, we need Qt 5.6, otherwise newer LTS should be good (e.g. 5.12). Of course, you could use a more recent version of Qt in your plugins than qapplication was built with. In this case, you would need to distribute your own Qt dlls, and make sure the users overwrite the ones distributed with the qapplication plugin. This could be a source of problems, so I think it is better if we agree on a single version, at least for Windows.

from dfhack-qt.

Yes, I need to make a git submodule of you repo in my plugin. That way it will be always syncronized.

About deployment, I need to think about it

from dfhack-qt.

Today I debugged the linux crash and found that it happens at main.cpp, function app_exec in the line Application app(argc, argv); I've tried to follow all solutions that Google told me without sucess.

So, yes it will be needed for the client to install qt5 using apt-get, yum, etc and we need to compile the plugin using a "old" qt version in Linux.

For Windows, I think that the first version with MSVC2015 (the one that Toady uses for Dwarf Fortress) would be ok. That's Qt 5.6 I think. Or the one that uses Dwarf Therapist

What do you think?. Please choose a Qt version for Linux and Windows and I'll use these ones. It will be a big pain in the ass to set-up a development environment again, but ...

PD: What branch should I use for making a submodule of qapplication?.

from dfhack-qt.

Today I debugged the linux crash and found that it happens at main.cpp, function app_exec in the line Application app(argc, argv); I've tried to follow all solutions that Google told me without sucess.

Did it happened when you try to deploy your plugin or is it unrelated? Anyway if you want help, I need more details: how to reproduce the bug or a detailed backtrace.

So, yes it will be needed for the client to install qt5 using apt-get, yum, etc and we need to compile the plugin using a "old" qt version in Linux.

For Windows, I think that the first version with MSVC2015 (the one that Toady uses for Dwarf Fortress) would be ok. That's Qt 5.6 I think. Or the one that uses Dwarf Therapist

DT uses 5.6 on Windows (for XP compatibility), 5.2 for the Linux appimage (may switch to 5.5 later), 5.5 on macOS (but it will be 5.12 for the next release).

I checked on distrowatch the common stable distros I could think of:

• Ubuntu 16.04 Xenial: Qt 5.5, glibc 2.23
• Ubuntu 14.04 Trusty: Qt 5.2, glibc 2.19
• Debian Stretch (oldstable): Qt 5.7, glibc 2.24
• Debian Jessie (oldoldstable): Qt 4, glibc 2.19
• CentOS 7: Qt 5.9, glibc 2.17
• CentOS 6: Qt 4, glibc 2.12
• OpenSUSE 15: Qt 5.9, glibc 2.26
• OpenSUSE 42.3 (EOL last month): Qt 5.6, glibc 2.22

Trusty Xenial looks good to me, we're missing CentOS which is hard to target anyway, Debian jessie (very old but still supported, no Qt 5, so no easy way), OpenSUSE 42.3 (support just ended).

It will be a big pain in the ass to set-up a development environment again, but ...

What are your difficulties? On Windows, you are using non standard prefixes anyway, it is easy to install multiple versions side by side and select the version by setting CMAKE_PREFIX_PATH. On Linux, I use my own distro (fedora) version, and use Travis CI to check that it compile or deploy it with the older version.

What branch should I use for making a submodule of qapplication?

Ideally "master" only, other branches are working branches, they may have their history changed and are not reliable.

from dfhack-qt.

Today I debugged the linux crash and found that it happens at main.cpp, function app_exec in the line Application app(argc, argv); I've tried to follow all solutions that Google told me without sucess.

Did it happened when you try to deploy your plugin or is it unrelated? Anyway if you want help, I need more details: how to reproduce the bug or a detailed backtrace.

I started gdb, attached to Dwarf Fortress and set a breakpoint in the qapplication functions. Then typed enable qapplication and went step by step. Everything was working ok, the future, the thread creation etc until the moment that it creates the QApplication. I got a raise exception and the crash.

DT uses 5.6 on Windows (for XP compatibility), 5.2 for the Linux appimage (may switch to 5.5 later), 5.5 on macOS (but it will be 5.12 for the next release).

I checked on distrowatch the common stable distros I could think of:

* Ubuntu 16.04 Xenial: Qt 5.5, glibc 2.23

* Ubuntu 14.04 Trusty: Qt 5.2, glibc 2.19

* Debian Stretch (oldstable): Qt 5.7, glibc 2.24

* Debian Jessie (oldoldstable): Qt 4, glibc 2.19

* CentOS 7: Qt 5.9, glibc 2.17

* CentOS 6: Qt 4, glibc 2.12

* OpenSUSE 15: Qt 5.9, glibc 2.26

* OpenSUSE 42.3 (EOL last month): Qt 5.6, glibc 2.22

Trusty looks good to me, we're missing CentOS which is hard to target anyway, Debian jessie (very old but still supported, no Qt 5, so no easy way), OpenSUSE 42.3 (support just ended).

I'l use Qt 5.6.3 as is the last release of the 5.6 series on Windows. For Linux I´ll install a Trusty VM and make the development there.

What branch should I use for making a submodule of qapplication?

Ideally "master" only, other branches are working branches, they may have their history changed and are not reliable.

OK, master then. I saw recent activity in the development brach. It would be good if you merge that in master. I'll be try it anyway :)

from dfhack-qt.

I started gdb, attached to Dwarf Fortress and set a breakpoint in the qapplication functions. Then typed enable qapplication and went step by step. Everything was working ok, the future, the thread creation etc until the moment that it creates the QApplication. I got a raise exception and the crash.

It does not happens for me. The QApplication constructor does a lot of stuff. What is the exception and where was it thrown (you can use "catch throw" for gdb to stop when the exception is thrown instead of when the program terminate).

I'l use Qt 5.6.3 as is the last release of the 5.6 series on Windows. For Linux I´ll install a Trusty VM and make the development there.

Sorry, I meant Xenial.

OK, master then. I saw recent activity in the development brach. It would be good if you merge that in master. I'll be try it anyway :)

I want to finish my travis script first.

from dfhack-qt.

Try these. I tested quickly on Debian 9, and Fedora 30 and it worked for me except for the known crash when quitting (because of SDL incompatibility).

from dfhack-qt.

I installed qapplication for Qt5.5 and it works in a fresh xenial VM. My plugin not.

ldd on my plugin gives
./dwarfexplorer.plug.so: /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5: versionQt_5' not found (required by ./dwarfexplorer.plug.so)
./dwarfexplorer.plug.so: /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5: version Qt_5' not found (required by ./dwarfexplorer.plug.so) ./dwarfexplorer.plug.so: /usr/lib/x86_64-linux-gnu/libQt5Core.so.5: version Qt_5.12' not found (required by ./dwarfexplorer.plug.so)
./dwarfexplorer.plug.so: /usr/lib/x86_64-linux-gnu/libQt5Core.so.5: version `Qt_5' not found (required by ./dwarfexplorer.plug.so)

Still trying to find Qt5.12.

Anyway I'll setup a dev environment in the virtual machine and try to compile dfhack and the plugin for Qt5.5

`

from dfhack-qt.

To use the plugin on Debian/Ubuntu you need to install libqt5widgets5 (for building you need qtbase5-dev). You can check my travis script to see how it is built: https://github.com/cvuchener/dfhack-qt/blob/develop/.travis.yml.

from dfhack-qt.

Well. I don't know what to think.
I compiled the plugin in Xenial, started dfhack and enabled qapplication: OK. launch my plugin dwarfexplorer: OK. I get the MainWindow, with its toolbar, etc. Everything seems fine.

But as soon as I press the suspend button, the plugin locks. With gdb, I found that the problem is in CoreSuspender. that doesn't work. DF keeps running and CoreSuspender locks and hence my plugin.

So Qt works but I don't know why CoreSuspender doesn't.

Then I took the compiled plugins (Qt5.5) of the Xenial VM and put them in my linux machine (Ubuntu 19.04). And there works. I've ldd the plugin and all the .so are the system ones, not the Qt 5.12 ones

I don't know what to think. Could you check my plugin in your linux box?.
release

from dfhack-qt.

It happens with gcc-4.8 version of DFHack, but not the gcc-7 version.

Also, you did not compile the plugin using the correct version of DFHack, checkout 0.44.12-r2 before compiling.

Warning: Plugin dwarfexplorer compiled for DFHack 0.44.12-r2-24-gc8bb0048, running DFHack 0.44.12-r2-0-g315852a2

from dfhack-qt.

I updated my gcc from gcc5 to gcc6, compiled and it runs now. I don't know if the problem was the dfhack that comes with the Linux LNP because yesterday I put the .so in the hack folder of the LNP. Today I did a full compilation and make install, so I replaced the LNP dfhack.. I need to check it again. I'll check with a fresh 18.04 VM.

About the dfhack version mismatch, I know, there was a lot of interesting changes in df structures since the original release. That's not a problem. I'll generate a 44.12 plugin from master, not from develop.

Did you have some time to play with the plugin?. Did it crash?.

from dfhack-qt.

I made more tests with my labors plugin: https://github.com/cvuchener/dfhack-qt/releases/tag/labors-test

The version without gcc version number uses Xenial's default gcc (5.3). With dfhack-gcc-4.8, gcc-4.8 works, gcc and gcc-7 hang. With dfhack-gcc-7, gcc-4.8 hangs, gcc and gcc-7 work. There must have been a change in mutexes with gcc-5 that makes them incompatible.

So, we will need two releases, one with gcc-4.8, the other with gcc-7 to match the releases from dfhack.

Note: if you want to test the qtlabors plugin, you will need to copy the gridviews from Dwarf Therapist in DF folder.

from dfhack-qt.

Well
I tested qtlabors in a fresh Bionic Ubuntu machine with a Linux LNP.
It only works with gcc4.8. qapplication works in all 3 systems, but qt-labors only in gcc4.8
That means that LNP dfhack is compiled with gcc4.8?. Is it the libc version? I'm not a expert in this kind of things.

If you compile your DFhack, it will work, of course, but I don't expect people compiling its own dfhack. This should be plug and play. Just Install qt5-base and copy the plugins to the /hack folder

My plugin (compiled with gcc6) doesn't work with the LNP. I'll need to compile for gcc4.8

I'll try to contact the LNP creator and ask what gcc version use . I'm lost right now. I don't know what to do to make my plugin work with the LNP

from dfhack-qt.

qapplication works because it does not use CoreSuspender (so it is not sharing a mutex with core dfhack).
It is directly related to glibc or libstdc++ libraries, since I used the same for all my tests. It must come from the c++ headers.

DFHack has two release types, so I'll make the corresponding plugins. I hope LinuxLNP uses one of these and not a third version. You can use the checksum of libdfhack.so, if you want to be sure. I expect it uses the gcc-4.8 version from what you reported.

from dfhack-qt.

The LNP use dfhack releases.

I tried a gcc4.8 compilation of the plugin and now it works in Beaver with LNP. Finally :)

Yes, we need to provide two downloads. One for gcc4.8 and another for gcc7.

Now to do the same for Windows

from dfhack-qt.

I made a release with linux and windows builds: https://github.com/cvuchener/dfhack-qt/releases/tag/beta1

from dfhack-qt.

Hmmm.
Is there anything new?. I only need

• qapplication.dll
• Qt5Core.dll
• Qt5Gui.dll
• Qt5Widgets.dll
• qwindows.dll

The last one in a platforms subdirectory of DF. The other ones that you include in the relesase are not needed (at least to run my plugin).

PD: I added your repo as a git submodule, so it will be updated every time that I compile it.

Also, I'm finishing a Linux release of my plugin (with gcc4.8 and gcc8 versions). The same as dfhack releases.

from dfhack-qt.