We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 2249

Summary: [X11] Improve loading of dynamic libraries
Product: SDL Reporter: Gabriel Jacobo <gabomdq>
Component: videoAssignee: Ryan C. Gordon <icculus>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: enhancement    
Priority: P2    
Version: HG 2.1   
Hardware: All   
OS: Linux   

Description Gabriel Jacobo 2013-11-18 12:08:08 UTC 
Ref: https://twitter.com/icculus/status/402174419910414337

It seems the current X11 code tries to load the required runtime libraries based on information obtained on the build system, which can be problematic (building on a 64 bits, running on 32, or maybe running in a different distro entirely). Given X11_GetSym just goes through all the known libs trying to find the symbol it needs, maybe this can be solved by hardcoding a bunch of known paths in there (or taking a X11 prefix via a hint).
Comment 1 Ryan C. Gordon 2013-11-19 06:42:58 UTC 
I haven't looked at why this happened yet; project referenced by that tweet is statically linking SDL2 to OpenFL, so it's possible they didn't even _use_ the configure script. Checking that is next on my TODO list.

The configure script magic wasn't mine (Sam, was this you?), and was probably there to deal with a large array of ancient Unix systems in the late 1990's. In an x.org world, we should probably just hardcode libX11.so.6 and be done with it.  :)

--ryan.
Comment 2 Ryan C. Gordon 2013-11-19 07:10:54 UTC 
Okay, I looked at OpenFL.

Here's the actual, immediate problem:

    https://hg.libsdl.org/SDL/file/6516c66db5c9/cmake/sdlchecks.cmake#l297

The CMake project doesn't do all that magic, it just asks CMake to find the .so it should link against and strips off any path info.

Naturally, CMake wants you to link against the .so file (and the linker will figure out the right SONAME from there, as it should), but this mechanism isn't appropriate for figuring out what to dlopen() later.

--ryan.
Comment 3 Ryan C. Gordon 2013-11-19 20:29:44 UTC 
Fixed in https://hg.libsdl.org/SDL/rev/d84a30e5cbd5

I'm going to resolve this bug, even though this was actually a symptom of the problem Gabriel referenced and not the problem itself.

Specifically: we link against a specific SONAME (libX11.so.6) because that's the API version we intend to target. If a system has libX11.so.7, if such a thing ever exists, the explicit reason that number changed is because the API is no longer compatible with .6 ...so going through a list of libs at runtime wouldn't be safe; it actually _has_ to match what the build machine found.

This isn't any different than if we had linked with -lX11 instead of used dlopen() on it.

--ryan.