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 3869 - [udev] SDL_UDEV_DYNAMIC only checks for one libudev version
Summary: [udev] SDL_UDEV_DYNAMIC only checks for one libudev version
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: joystick (show other bugs)
Version: 2.0.6
Hardware: All Linux
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-10-10 15:53 UTC by Ethan Lee
Modified: 2017-10-11 20:33 UTC (History)
1 user (show)

See Also:


Attachments
Fix for SDL_UDEV_DYNAMIC/SDL_UDEV_LIBS (1.42 KB, patch)
2017-10-11 00:24 UTC, Ethan Lee
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ethan Lee 2017-10-10 15:53:19 UTC
This commit appears to have introduced a bug where SDL will forcibly depend on a single udev version, rather than prioritizing one or the other:

https://hg.libsdl.org/SDL/rev/1ae4e8001b73

For example, if the build system has libudev.so.1 and the user has libudev.so.0, even if the game does not link to libudev at all the game will fail to detect devices for the user:

http://steamcommunity.com/app/543260/discussions/0/1471966894869753969/?ctp=2#c1489987634012244580

I don't know the full context for this commit so I'm not sure about this, but would it make more sense to have SDL_UDEV_DYNAMIC be a separate thing entirely and _then_ check for the list if SDL_UDEV_DYNAMIC isn't found? For example:



static const char *SDL_UDEV_LIBS[] = { "libudev.so.1", "libudev.so.0" };

#ifdef SDL_UDEV_DYNAMIC
_this->udev_handle = SDL_LoadObject(SDL_UDEV_DYNAMIC);
if (_this->udev_handle != NULL) {
    /* blah... */
    return retval; /* ...? */
}
#endif

for( i = 0 ; i < SDL_arraysize(SDL_UDEV_LIBS); i++) {
    /* You get the idea... */
}



Again, this is entirely a guess, but it does seem like we should at the very least have the full list of udev libs for the case where the executable doesn't directly link to udev.
Comment 1 Sam Lantinga 2017-10-10 22:45:10 UTC
Not a bad idea, do you want to provide a tested patch?

Thanks!
Comment 2 Ethan Lee 2017-10-11 00:24:07 UTC
Created attachment 2972 [details]
Fix for SDL_UDEV_DYNAMIC/SDL_UDEV_LIBS

Attached is the patch implementing my idea, will send a patched binary to the user with this issue and report back (if someone else doesn't test this first).
Comment 3 Ethan Lee 2017-10-11 03:33:15 UTC
Looks like the patch worked! This should be good to merge provided we haven’t missed a case other than so.0 and so.1...
Comment 4 Sam Lantinga 2017-10-11 20:33:09 UTC
Added, thanks!
https://hg.libsdl.org/SDL/rev/0f2de8f6c959