-
Notifications
You must be signed in to change notification settings - Fork 174
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[2.x] Autotools build can detect the wrong libjpeg #433
Comments
I tried to simulate this by putting libjpeg-turbo and ijg libraries in the same place, like: $ ls -l ~/x2/lib/*
total 1200
lrwxrwxrwx. 1 ozkan ozkan 16 Mar 11 21:26 libjpeg.so -> libjpeg.so.9.6.0
lrwxrwxrwx. 1 ozkan ozkan 17 Mar 11 21:28 libjpeg.so.62 -> libjpeg.so.62.0.0
-rwxr-xr-x. 1 ozkan ozkan 291256 Dec 10 2013 libjpeg.so.62.0.0
lrwxrwxrwx. 1 ozkan ozkan 16 Mar 11 21:26 libjpeg.so.9 -> libjpeg.so.9.6.0
-rwxr-xr-x. 1 ozkan ozkan 929643 Mar 11 21:26 libjpeg.so.9.6.0
drwxrwxr-x. 2 ozkan ozkan 4096 Mar 11 21:26 pkgconfig .. and then, configuring SDL_image like When both are present:
|
Linking a project with CMake selects the correct library by following the symbolic links and then looking in the same directory for other files linking to |
In my reproducer,
Whichever one the headers and the |
That's a fundamental deficiency of |
For my use-case, it would be enough to have a configure option or an |
That actually sounds like a good solution to me |
Messing with |
It might be better not to make this critical-path for SDL 2.8.x. |
Let's go with your AC_ARG_WITH solution then (but we should make it for every lib-to-be-detected in there.) Do you have a patch? |
It is possible to have multiple dynamic shared libraries for libjpeg, for example in the Steam Runtime 1 'scout' SDK, which has development headers and a runtime library for libjpeg-turbo (installed as libjpeg.so.8), but also has the runtime library for IJG libjpeg 6b (installed as libjpeg.so.62). Allow an invocation like ./configure --enable-jpg-shared=libjpeg.so.8 ... to force the use of a specific SONAME. Resolves: libsdl-org#433 Signed-off-by: Simon McVittie <smcv@collabora.com>
#434 does this for libjpeg, by overloading
In practice, I think libjpeg is the only one of the libraries we link that has multiple competing implementations, and also the only one where the highest number is not necessarily the "best". We could extend the same treatment to avif, jxl, png, tif relatively easily. We cannot easily do the same thing for webp, because webp dlopens two libraries, not just one - so we'd have to invent a new For 3.x, Autotools has gone away completely, which is part of why I don't think it's necessarily worth investing a whole lot of effort in it. |
It is possible to have multiple dynamic shared libraries for libjpeg, for example in the Steam Runtime 1 'scout' SDK, which has development headers and a runtime library for libjpeg-turbo (installed as libjpeg.so.8), but also has the runtime library for IJG libjpeg 6b (installed as libjpeg.so.62). Allow an invocation like ./configure --enable-jpg-shared=libjpeg.so.8 ... to force the use of a specific SONAME. Resolves: #433 Signed-off-by: Simon McVittie <smcv@collabora.com>
It is possible to have multiple dynamic shared libraries for libjpeg, for example in the Steam Runtime 1 'scout' SDK, which has development headers and a runtime library for libjpeg-turbo (installed as libjpeg.so.8), but also has the runtime library for IJG libjpeg 6b (installed as libjpeg.so.62). Allow an invocation like ./configure --enable-jpg-shared=libjpeg.so.8 ... to force the use of a specific SONAME. Resolves: #433 Signed-off-by: Simon McVittie <smcv@collabora.com> (cherry picked from commit 044e7a7)
To reproduce
Note that in the scout SDK,
/usr/include/jpeglib.h
and/usr/lib/x86_64-linux-gnu/libjpeg.so
are provided bylibjpeg-turbo8-dev
(libjpeg-turbo built to be compatible with the ABI of IJG libjpeg 8), but/usr/lib/x86_64-linux-gnu/
contains both:and
where the latter is provided by IJG libjpeg version 6b.
Expected result
All tests pass.
Actual result
A CMake build from the same sources succeeds.
Looking at the build log, one thing that jumps out at me is:
This means that the libjpeg whose headers we
#include
(libjpeg-turbo, SONAMElibjpeg.so.8
) is not the same as the libjpeg that we dlopen (IJG libjpeg, SONAMElibjpeg.so.62
). libjpeg is sufficiently fault-tolerant that it manages to detect this incompatibility and report a recoverable error, rather than just crashing.I think this is the root cause for why I experienced #428 and #429, which can only happen in an error-handling code path.
Workarounds
--disable-jpg-shared
so that the chosen flavour of libjpeg is a hard dependency. We do this in Debian, Ubuntu, and the container-based Steam Runtime ≥ 2 branches; but we do not currently do this in Steam Runtime 1, so that the Steam Runtime 1 binary of SDL_image can be copied and pasted into games' portable non-Steam binary builds.--disable-stb-image
so that stb_image is used instead of libjpeg (untested, but should work).The text was updated successfully, but these errors were encountered: