[2.x] Autotools build can detect the wrong libjpeg about sdl_image

[sezero]

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 LDFLAGS=-L~/x2/lib ../configure --disable-stb-image
gives me -- dynamic libjpeg -> libjpeg.so.62

When both are present:

• Which one do the headers actually belong?
• Which one does configure pick for you? and ..
• which one do you really want?

[madebr]

Linking a project with -ljpeg will select libjpeg.so -> libjpeg.so.9.6.0. So the headers (should) belong to 9.6.0.

CMake selects the correct library by following the symbolic links and then looking in the same directory for other files linking to libjpeg.so.9.6.0, of which it selects libjpeg.so.9.
libjpeg.so -> libjpeg.so.9.6.0 -> libjpeg.so.9.

[smcv]

• [To] Which one do the headers actually belong?

In my reproducer, libjpeg.so.8.

• Which one does configure pick for you?

libjpeg.so.62 (I think because 62 is more than 8, even though actually it's a strange way of writing 6b and is semantically more like 6.2)

• which one do you really want?

Whichever one the headers and the libjpeg.so symlink belong to, which in my case is libjpeg.so.8.

[sezero]

That's a fundamental deficiency of find_lib. Do we not have a way of following lib*.so symlinks by common shell tools?

[smcv]

For my use-case, it would be enough to have a configure option or an AC_ARG_VAR that lets me say "don't auto-detect, I'll tell you the right answer: it is libjpeg.so.8".

[sezero]

For my use-case, it would be enough to have a configure option or an AC_ARG_VAR that lets me say "don't auto-detect, I'll tell you the right answer: it is libjpeg.so.8".

That actually sounds like a good solution to me

[sezero]

Do we not have a way of following lib*.so symlinks by common shell tools?

Messing with readlink result might help with this?

[smcv]

Messing with readlink result might help with this?

It might be better not to make this critical-path for SDL 2.8.x.

[sezero]

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?

[smcv]

#434 does this for libjpeg, by overloading --enable-jpg-shared to take three classes of value:

• literal no: link libjpeg in the normal way (not using dlopen), as is done in e.g. Debian
• literal yes: auto-detect what to dlopen
• anything else: dlopen that SONAME

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 --enable-webpdemux-shared=SONAME or something. I'd prefer not to get into that for 2.x, and certainly not for 2.8.x.

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.