error while loading shared libraries: libgdk-x11-2.0.so.0

[SilverGreen93]

Just downloaded the Linux 64-bit Intel binary from 1.50 release, but I get this error at launch:

❯ ./DiscImageManager
./DiscImageManager: error while loading shared libraries: libgdk-x11-2.0.so.0: cannot open shared object file: No such file or directory

I am on Manjaro (Arch Linux based, KDE Plasma, Wayland) and I cannot find any package providing the required lib. What should I do?

[geraldholdsworth]

Phil Pemberton has found this issue and has done sterling work in splitting the CLI and GUI, which is the issue you're facing.
See Issue 39, and Pull Requests 41, 42 and 43.
See also my attempt (not yet compiled) with Issue 49.

The CLI only binary should be included in the ZIP file in the downloads.

[geraldholdsworth]

I've been checking and, for some reason, DiscImageManagerCLI never got included into the zip files.

I've got my version of the console only version almost ready - had to iron out a few bugs - so should be ready to make it publicly available in the next couple of days.

[SilverGreen93]

Thanks for the replies. I will test the next release GUI and CLI and report if the issues are fixed.

[geraldholdsworth]

This appears to be a common problem. There is a solution here.
And this explains what it is:
Meaning that the CLI only version of DIM should get around this...if you don't need the GUI, that is.

[SilverGreen93]

This appears to be a common problem. There is a solution here. And this explains what it is: Meaning that the CLI only version of DIM should get around this...if you don't need the GUI, that is.

I just did a check:

❯ file DiscImageManager 
DiscImageManager: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.4.0, stripped

❯ ldd DiscImageManager 
        linux-vdso.so.1 (0x00007f885091f000)
        libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f88508ca000)
        libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f88508c5000)
        libgdk-x11-2.0.so.0 => not found
        libgtk-x11-2.0.so.0 => not found
        libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f8850781000)
[...]

It seems that your executable is NOT 32-bit, so I don't see how the fix you linked to applies here. I still get the error below and I don't really know what to do to use the GUI version.

❯ ./DiscImageManager             
./DiscImageManager: error while loading shared libraries: libgdk-x11-2.0.so.0: cannot open shared object file: No such file or directory

I am on Manjaro (Arch Linux).

I think gtk2 packages are obsolete:

❯ sudo pacman -S gtk2       
error: target not found: gtk2

[geraldholdsworth]

No, the 64-bit version of the executable is not 32-bit, it is 64-bit. There is a clue in the name. There is a separate download for 32-bit.
Have you tried the DIMConsole executable which should now be packaged as part of the distro?

[SilverGreen93]

Have you tried the DIMConsole executable which should now be packaged as part of the distro?

Yes, the console application works.

I managed to find the gtk2 package in AUR reporsitory, installed it, but when I try to start the GUI application, it is still a console application. How do I launch the GUI?

❯ ./DiscImageManager

(DiscImageManager:77296): Gtk-WARNING **: 21:17:30.698: Unable to locate theme engine in module_path: "adwaita",
********************************************************************************
Disc Image Manager Console V1.50.4 by Gerald J Holdsworth

Linux Intel 64 bit

Ready
>

[geraldholdsworth]

I added something a few versions back to try and detect how the application was started, so that if it started from Terminal/Bash it would fire up the Console, otherwise fire up the GUI. This worked find in Windows and macOS but, as you've found, doesn't do so well in Linux.
So, I added a switch '-g' or '--gui' to force it into GUI. You'll need:
./DiscImageManager -g

[SilverGreen93]

Thanks! That did the trick. Using -g started the GUI.

Just a note, if you now provide separate executables for GUI and CLI, maybe a good idea would be to start the GUI by default when launching the GUI executable, without requiring the -g option.