Multimc5: libqxcb.so is missing

[dje4321]

The latest dev branch is preventing multimc from finding libqxcb.so. The file does exist in plugins/platforms. Appears to be affecting older and fresh installs of multimc

Error when running MultiMC
https://hastebin.com/neyahuzewi.vbs

MultiMC-0.log
https://hastebin.com/neyahuzewi.vbs

Running the latest install of fedora 27

[michaellindman]

I am experiencing this with multimc not finding libqxcb.so. I am also on Fedora 27.

[peterix]

Yeah. I updated Qt to 5.6.3 and moved builds to an Ubuntu Trusty VM. This brought some weird new issues, as you can see.

I'm not sure how should the linux builds be packaged right now, but I'm leaning towards not including the dependencies at all.

All these would be gone:

And the launch script would be re-done to notify about missing direct dependencies.

The other idea would be to go chase some runtime linking issues in Qt plugins across different distributions...

Other than that, I don't know. Do you see other options?

[peterix]

The dependencies would then be zlib, recent enough glibc and libstdc++ and Qt 5.6(.3)?. This would need testing.

[dje4321]

i like having the dependencies built into multimc as its the only QT based app i use

[peterix]

That's nice, but bundling it is becoming unworkable. It has way too many dependencies. On the other hand the interface between MultiMC and its immediate dependencies is fairly minimal. As long as your distro has Qt 5.6, it should work without any issues.

I'll go through it with LD_DEBUG and see what I find.

[peterix]

OK. It's actually the bundled version of zlib conflicting with libpng ... at least on Arch. Delete the libz so file, see if it helps.

[peterix]

And I guess I'm bundling the wrong libpng ... hmm.

[dje4321]

So this is what ive found so far.

running ldd with the LD_LIBRARY_PATH points to bin/

libQt5XcbQpa.so.5:
./libQt5XcbQpa.so.5: /home/dje4321/Downloads/mmc-stable-lin64/MultiMC/bin/libz.so.1: version `ZLIB_1.2.9' not found (required by /lib64/libpng16.so.16)

Also if you use LD_PRELOAD to load plugins/platforms/libqxcb.so and run MultiMC it will spit out this error

./MultiMC: /home/dje4321/Downloads/mmc-stable-lin64/MultiMC/bin/libz.so.1: version `ZLIB_1.2.9' not found (required by /lib64/libpng16.so.16)

[dje4321]

and deleting the libz file does nothing

if i preload the plugins/platform/libqxcb.so.1 file then it complains about a missing symbol

./MultiMC: symbol lookup error: ../plugins/platforms/libqxcb.so: undefined symbol: _ZNK21QPlatformBackingStore9toTextureERK7QRegionP5QSizePb

[peterix]

Well, that is a Qt symbol, so the plugin probably doesn't see the bin folder. All the other binaries and libraries do, because they have RPATH set internally.

[peterix]

It should work if you remove the bundled zlib. At least it does here.

I'll have to test with a bunch of different distros.

[dje4321]

seems to be working now for some reaon after removing zlib

[peterix]

Yeah. I am bundling libpng12, but the new build setup requires libpng16. Including zlib collides with the system libpng16, because I'm not bundling it. And yes, this is black magic.

It would be better to make the bundled deps optional. Sort of like Steam is packaged -- you can run with or without the Steam runtime.

[peterix]

OK. Took a closer look at it and these are the take-away points:

1. The situation is different than I thought previously - actually, the qxcb plugin (bundled) depends on freetype (system), which depends on libpng16 (system, in conflict with bundled libpng12, it's a miracle that works), which depends on libz (system). And when I bundle libz, it ends up not working because the one I got replaces the system one and is older. I would have to keep the bundled libs always current to avoid such situations. I can either push new versions hard to make things not break on new distros or keep using ancient versions to stay compatible with old distros. Neither is good.
2. This is basically the DLL hell from the times of Windows 95.
3. Therefore I am removing the bundled libz.
4. Linux needs a desktop application runtime with a stable API and ABI, where newer versions of the runtime work with software built for older versions.
5. Because distros differ and the linux desktop in general doesn't provide a stable runtime for Qt to sit on top of, bundling Qt on linux is honestly crazy. I don't know what I would have to do for it to work, probably bundle most of the system and end up with a 150MB download like all the Electron apps.
6. Things like flatpak don't solve the problem, because their runtimes are not built for the platform and don't integrate with the platform - you would have the same problem as with the currently bundled Qt. No theming and overall bad experience with things breaking randomly.
7. Qt alone is already this runtime, but it has to be built for and integrated with the rest of the system. This is part of its design! See: http://doc.qt.io/qt-5/qpa.html
8. I will target a sensible Qt release. Distros with older Qt or no Qt will not be supported in the future. It's not worth the trouble.
9. The distro packages for various distros should simply be the binaries with added dependencies on the local Qt packages.
10. I will aim for better packaging and delivery on linux - including repositories. But don't hold your breath, this will take some time to set up. The builds with bundled libraries will be eventually dropped when I have suitable replacements.

Consider this table:
https://en.wikipedia.org/wiki/Qt_version_history#Qt_5

Any distro with a Qt version that is lower than the oldest currently officially supported version (by The Qt Company or whoever maintains Qt at the time) will NOT be supported, because that is the version I will build for.

MultiMC will use Qt 5.6 until March 2019, at which point I will switch it to 5.9.

5.9 means dropping Windows older than 7, macOS older than 10.10 and any distro that doesn't include Qt 5.9 or newer:
http://doc.qt.io/qt-5.9/supported-platforms.html

[peterix]

Alright, tested it on Arch, and it seems to work now.

[dje4321]

Works on fedora 27 also

[alyandon]

@peterix Just a heads up that Ubuntu 16.04 LTS packages Qt 5.5. I don't know how popular it is among your users or how much you care about keeping MultiMC working on that distro but I use it for stability and 5.5 was the current release when it was frozen less than 2 years ago.