Fedora 23 - undefined symbol: xcb_send_fd

[srakitnican]

Unable to run generic 64-bit version.

$ ~/Downloads/MultiMC/MultiMC
MultiMC Dir: /home/user/Downloads/MultiMC
No missing dependencies found.
/home/user/Downloads/MultiMC/bin/MultiMC: symbol lookup error: /lib64/libxcb-dri3.so.0: undefined symbol: xcb_send_fd

As I found here: https://bugs.freedesktop.org/show_bug.cgi?id=73237 libxcb-dri3 should not define xcb_send_fd?

$ nm -D /lib64/libxcb-dri3.so.0 | grep xcb_send_fd
U xcb_send_fd
$ nm -D /lib64/libxcb.so.1 | grep xcb_send_fd
000000000000b0b0 T xcb_send_fd

[KuroNeko87]

Having same issue

[KuroNeko87]

I think it might be related to out of date libraries. Would it be possible to have multimc to get the libraries from the system and not its own folder?

[peterix]

Yes. Delete the ones MultiMC comes with. Or at least some of them. Any and all of the xcb stuff.

It's possible it is broken beyond repair, but removing the libs would be a way to test it.

I've downloaded the fedora 23 workstation ISO, but haven't gotten to testing it yet.

[KuroNeko87]

remove everything libxcb, this is what i got.

[eroman@kuroneko87-Inspiron-N5050 MultiMC]$ ./MultiMC
MultiMC Dir: /home/eroman/Downloads/MultiMC
No missing dependencies found.
This application failed to start because it could not find or load the Qt platform plugin "xcb".

Reinstalling the application may fix this problem.
./MultiMC: line 84: 32102 Aborted (core dumped) "${MMC_DIR}/bin/MultiMC" -d "${MMC_DIR}" $@
[eroman@kuroneko87-Inspiron-N5050 MultiMC]$

[peterix]

have you removed the plugin?

[KuroNeko87]

from platforms folder, yes

[peterix]

Then put it back.

[KuroNeko87]

Alright, that went better but now asks for another dependency, i'm trying to look for it. Seemd it has been deprecated last release of the package was for fedora 20.

Here's the output.

[eroman@kuroneko87-Inspiron-N5050 MultiMC]$ ./MultiMC
MultiMC Dir: /home/eroman/Downloads/MultiMC
Yum command has been deprecated, redirecting to '/usr/bin/dnf whatprovides libxcb-sync.so.0'.
See 'man dnf' and 'man yum2dnf' for more information.
To transfer transaction metadata from yum to DNF, run:
'dnf install python-dnf-plugins-extras-migrate && dnf-2 migrate'

Error: No Matches found
Error: MultiMC is missing the following libraries that it needs to work correctly:
libxcb-sync.so.0,
Please install them from your distribution's package manager.

Hint: sudo yum install Last

I have normal libxcb installed

[root@kuroneko87-Inspiron-N5050 ~]# dnf install libxcb
Failed to synchronize cache for repo 'Dropbox' from 'http://linux.dropbox.com/fedora/23/': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried, disabling.
Last metadata expiration check performed 2:22:18 ago on Fri Jan 1 14:46:36 2016.
Package libxcb-1.11.1-1.fc23.x86_64 is already installed, skipping.
Package libxcb-1.11.1-1.fc23.i686 is already installed, skipping.
Dependencies resolved.
Nothing to do.
Complete!

[peterix]

Looking at this, you may just have to build it yourself.

[KuroNeko87]

https://rpmfind.net/linux/rpm2html/search.php?query=libxcb-sync.so.0
this is what i found

[KuroNeko87]

never worked on C++ should be fun :p

[peterix]

See: https://github.com/MultiMC/MultiMC5/blob/develop/BUILD.md

[srakitnican]

Good news :)

Removing libxcb from launcher does the trick!

$ rm ~/Downloads/MultiMC/bin/libxcb.so.1
$ ~/Downloads/MultiMC/MultiMC
MultiMC Dir: /home/user/Downloads/MultiMC
No missing dependencies found.
0.036 C "Failed to read the account list file (accounts.json)."
0.088 W Blacklisted legacy version ignored: "rd-160052"
0.385 W STDERR ""
0.395 W STDERR ""
0.604 W Blacklisted legacy version ignored: "rd-160052"

Launcher launched, and window appeared!

[KuroNeko87]

oh that's great

[KuroNeko87]

+1 confirm. Just removing libxcb.so.1 from bin solves the problem

[peterix]

Fedora 23 can actually run MultiMC as is. It has Qt 5.5.1. So if the distro can run it, we shouldn't need to supply all those libs.

Let's do it this way.

[peterix]

http://www.megafileupload.com/a0ii/MultiMC-fedora-23.tar.gz

This works. It can be packaged just fine. Needs a spec file with the deps set, the .desktop file, maybe a custom runner script and an icon.

[peterix]

OK. I am going to postpone this after 0.4.8. The workarounds have been described well enough here.

[nikhiljha]

It's still an issue but the fix here works for F24 as well.

[srakitnican]

Hello again!

I took some time to look at packaging and I finally think I am ready to make my attempt at packaging MultiMC. So, the repository would be available on copr for a start, maybe later included in official repository if legal issues permits so. But I am not sure of couple of issues.

Since MultiMC have its own update mechanism, this would need to be disabled in packaging version. Noticed the Apache licence and naming issues, but not sure what redistributable exactly means. Am I allowed to package this source under the name of MultiMC?

[peterix]

@srakitnican sorry for the delay.

You can look at how it's packaged in Arch AUR for example:
https://aur.archlinux.org/packages/multimc5/

Basically, it doesn't include any Qt libraries or plugins and instead depends on the system version of Qt5. You could actually take the binaries below, strip the extra included Qt5 files and repackage that. It's built against Qt 5.4.x, so any newer version should work. The only other notable hard dependency is libz.

There are some optional dependencies:

• mcedit - for editing worlds
• jvisualvm - for profiling the game

And some things highly suggested to be present (the game needs them):

• Some JRE (not libgcj)
• Some opengl capable driver

As for using the name, I'd say it's OK as long as you do not break the Mojang authentication code (essentially crack the game). If you decide to use the binaries, there is no problem.

[peterix]

Also, this particular issue should be fixed in the develop builds now.

See:
https://files.multimc.org/downloads/mmc-develop-lin32.tar.gz
https://files.multimc.org/downloads/mmc-develop-lin64.tar.gz

[srakitnican]

I am not very familiar with development process so I am not sure what is possible or reasons why something is made like it is. Stuff that follows are my personal observations.

By Fedora packaging guidelines there are a couple of issues I have encountered while packaging the sources. So these should be addressed before submitting package for a review request, but there are no reasons I am aware of to just keep it in copr.

Following are some notes.

• Source code should be compilable without Internet access. MultiMC5 sources curentlly needs Internet access for at least quazip.
• Libraries should be made external as much as possible. One that caught attention is nbt++. So this particular library should be packaged separately.
• Does not compile on CentOS due to CMake version 2.8.12.2

Other then that I've managed to put something together that works. Packages and sources can be found here:
https://copr.fedorainfracloud.org/coprs/srakitnican/minecraft/package/multimc5/
http://copr-dist-git.fedorainfracloud.org/cgit/srakitnican/minecraft/multimc5.git

Thank you for the tips.

[peterix]

Yeah. It was not made with distro packaging in mind. I actually told people that they shouldn't do it before.

However, it's very hard to release binaries for 'desktop linux' that work everywhere. Even if it works, a minor change in the dependencies can break things.

So, the issues:
Quazip, quite honestly, is a pain.
It does not handle some obfuscated java jar files well (it breaks filenames inside the archives, which breaks the game). It also causes problems on Windows because of its odd handling of the zlib dependency there - this is one of the reasons why the official builds still use Qt 5.4.
I can also see that the way it's built doesn't quite mesh well with source RPMs and reproducible builds.

I will be looking into replacing or fixing it at some point.

Other libraries... Yes.
https://github.com/MultiMC/MultiMC5/tree/develop/libraries
... there are quite a few in there. Most of them ripped out of their original projects and heavily customized. I also do not target any particular OS or OS distribution, so I include everything that I can't assume would be present. Think a bare install of Windows XP.

I could rename the resulting binary files so they don't clash with any system versions you might have. So for example, it would look like 'libMultiMC-rainbow.so' instead of 'librainbow.so'.

As for CentOS -- CMake 3 was released 2 years ago. Either RHEL 7 missed that by a few months, or CMake 3 wasn't as mature as would be required -- 2 years ago.
Anyway I go by what I have on my dev machine and what the CI containers have. It's bad enough that I have to build on Windows XP and for OSX 10.7... Just keeping those working is a miracle. I'm not adding 'building on CentOS' to that.

[Conan-Kudo]

@peterix CMake 3.5 is available for RHEL/CentOS 7 via Fedora EPEL as the cmake3 package, with the binary being named cmake3.

[peterix]

Or you can grab it from the website, yes. That's not the point. It can't be built using the base system.

[peterix]

Alright, I made some changes to the libraries that are built as shared.

They now all have a MultiMC_ prefix, so they shouldn't conflict with any system libraries.

[nikhiljha]

Perfect, just installed f25. Nice timing.

Will building from source now fix it? Or was building from source always working?

[peterix]

The main issue here should be gone in both develop and stable now.

At least until something else breaks.

[peterix]

Tested with Fedora 25 Workstation and it seems to be working.