Prebuilt binary fails, because libjpeg8 doesn't exist in Debian

[shmerl]

I can't use pre-built binaries in Debian [testing], because libjpeg8 is simply not present in the current distro. Is it possible to replace it with other jpeg decoders?

Trying to load "rdsp-vanilla_x86_64.so" from "."...
Sys_LoadDll(./rdsp-vanilla_x86_64.so) failed: "Failed loading ./rdsp-vanilla_x86_64.so: libjpeg.so.8: cannot open shared object file: No such file or directory"
Trying to load "rdsp-vanilla_x86_64.so" from "."...
Sys_LoadDll(./rdsp-vanilla_x86_64.so) failed: "Failed loading ./rdsp-vanilla_x86_64.so: libjpeg.so.8: cannot open shared object file: No such file or directory"
Failed to load renderer

I'll try building it with libturbojpeg0-dev.

[ensiform]

Why does Debian have to be so different from everyone else 🤔. Let alone why can't it detect any available jpeg library. Also, what prebuilt are you using, from debian packages or builds.openjk.org? If the former, see the package maintainer @smcv

[shmerl]

I didn't know Debian has packages for OpenJK. I simply downloaded one from here.

I see now it's in experimental: https://tracker.debian.org/pkg/openjk and it indeed works with libjpeg62-turbo there. I'll try using Debian build (I was just going to build it from source, but this simplifies things a bit). Still, it's not the best situation when per-built binary above fails like this.

Let alone why can't it detect any available jpeg library

That's a problem of the pre-built binary. It's dynamically linked against: libjpeg.so.8

ldd rdsp-vanilla_x86_64.so 
        linux-vdso.so.1 (0x00007ffdf1dc3000)
        libjpeg.so.8 => not found
...

[shmerl]

Yep, Debian build from experimental works OK.

[ensiform]

That's a problem of the pre-built binary. It's dynamically linked against: libjpeg.so.8

No that's an issue with Debian missing/excluding libjpeg8 or at the very least not including a wrapper lib8 to whatever it supports in it's place. Dependency Hell made worse with Debian Dependency Hell 😈

Regardless, I can't control what it is using at this time on the pre-built as that is just what the travis-ci vm is presently linking against I assume.

[smcv]

If the prebuilt binaries are coming from Travis-CI, then it's Travis-CI that's being weird here, because it runs on ye olde Ubuntu... or if the prebuilt binaries are coming from some other platform, it's that platform that is weird for using libjpeg 8.

IJG libjpeg (unnecessarily?) changed its ABI between version 6b (the one every distribution used for a long time) and 7, then again in 8 and 9. For a while Debian and Ubuntu were tracking IJG libjpeg (while every other distro was switching to libjpeg-turbo, a fork of IJG libjpeg), so they went through several ABIs too. This was widely considered to be a mistake, and after much arguing with the Debian maintainer of IJG libjpeg, we switched to libjpeg-turbo. Unfortunately, the 3 and 5 year old versions of Ubuntu that Travis-CI inexplicably still uses are from before that changed.

libjpeg-turbo kept with the libjpeg 6b ABI, while also providing the only important feature from libjpeg8 from the point of view of an idTech3 engine (the memory source API) without breaking compatibility with libjpeg 6b.

If you want prebuilt binaries that will work everywhere, you're better off with the bundled libraries, or something like Flatpak that uses a set of runtime libraries that's independent of the host system (at some point I'll try to look into building OpenJK, ioquake3, iortcw in Flatpak). If you want prebuilt binaries that will work in most distributions without bundling libraries, you're actually better off with libjpeg(-turbo) 6b than with libjpeg8.

I don't think it's possible to provide a wrapper around libjpeg6b that implements the libjpeg8 ABI, because they provide incompatible definitions of the same symbols.

The whole thing is a horrible mess, and I wish the maintainers of low-level libraries like libjpeg and libpng were better at keeping their ABIs compatible over time.

It's possible to do builds on Travis-CI in a Docker container that runs on something less old than Ubuntu 14.04, if that would help? Debian 8 (current stable) or Ubuntu 16.04 (current LTS) both have libjpeg-turbo with the libjpeg 6b ABI.

[smcv]

Debian 8 (current stable) or Ubuntu 16.04 (current LTS) both have libjpeg-turbo with the libjpeg 6b ABI

Huh, no, this is even messier than I thought. All the major distros use libjpeg-turbo, but:

• Debian and Fedora build with the libjpeg 6b ABI (which is what the LSB specifies, and the libjpeg-turbo default; it's compatible with the last IJG libjpeg release before a different project leader took over and started breaking the ABI)
• Ubuntu and Arch Linux build with the libjpeg 8 ABI
• openSUSE has both, and it isn't clear to me which is considered to be the default

If you want binaries that will run everywhere I'm afraid you will have to build the bundled copy.

[smcv]

There's more background in https://lists.fedoraproject.org/pipermail/devel/2013-January/176281.html (the message from former libjpeg maintainer Tom Lane a bit later in the thread is particularly relevant).

[ouned]

this is a good example of why distributing programs on linux is beyond retarded luckily, it's finally going to get better now with flatpak etc.

[shmerl]

It's not necessarily going to make things better. Flatpak and etc. are a trade-off, which introduces a whole different can of worms, like never updated dependencies and etc. So some things will get better, while others worse.

[clawoflight]

Distributing source programs is actually amazing. It's just distributing binaries that doesn't work well :)

[ouned]

@clawoflight yeah sure

make "libjpeg not found" apt-get install libjpeg8-dev make "libpng2 not found" apt-get install libpng-dev make "libsdl2 not found" apt-get install libsdl2-dev make

ERROR: x.cpp Line 10: A error which was treated as a warning in a previous gcc version now is an error and compiling stops fix it make make install FINALLY

later you dont want it anymore so...

make uninstall ERROR: target uninstall not found D:

[clawoflight]

I meant including maintainers and a repository in the middle, not compiling from source yourself.

Though to be fair, that still works much better than on windows and mac.

@ouned for your specific problem: Why don't you use checkinstall: That will call make install and create a package for you, e.g. a .deb on debian-based distros.