With latest mesa 3f3aafbfeeb3939cb5cf710954ccefb8bbe9cff9, all gl clients fail with the message "loader.c:112: asserted_dlsym: Assertion `result' failed." I bisected to find the last good commit was d51dbe048afd2131eb3675e9cd868ce73325a61d. With 4556c734700da2dd95d4f148d6929a537882bade, x11 gl clients work without error but fail on wayland. Since 7bd95ec437a5b1052fa17780a9d66677ec1fdc35, both x11 and wayland gl clients fail with this error. Building with latest dri3 stack, installing mesa into a nonstandard prefix and setting LIBGL_DRIVERS_PATH and LD_LIBRARY_PATH.
I discovered this stems from the fact that libudev.so.1 does not exist on the system, since there is no systemd installed.
libudev.so.1 is part of the libudev1/systemd/systemd-lib package. Install it and add the package as runtime dependency in your build script.
Should there be a configure check added to make it clear?
(In reply to comment #3) > Should there be a configure check added to make it clear? Currently we check if libudev is available during compile/build time, and build the "offending" code only if it's present. Seems like you've built mesa on a system(environment) with libudev, and then ran it on another one that lacks the library.
(In reply to comment #4) > (In reply to comment #3) > > Should there be a configure check added to make it clear? > Currently we check if libudev is available during compile/build time, and > build the "offending" code only if it's present. > > Seems like you've built mesa on a system(environment) with libudev, and then > ran it on another one that lacks the library. I have libudev standalone package that provides libudev.so.0. Replacing the lib string in the code allows it to work. So it's checking for libudev but not explicitly what version, or if the library that is needed exists.
Indeed, mesa requires libudev v151, which provides libudev.so.0. So we can either bump the minimum required version or fall-back to libudev.so.0. I believe that Eric will be the judge of that.
*** Bug 74204 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > Indeed, mesa requires libudev v151, which provides libudev.so.0. > > So we can either bump the minimum required version or fall-back to > libudev.so.0. > > I believe that Eric will be the judge of that. Is there any workaround for that? I was trying to play with libraries in synaptic, but didn't succeed.
(In reply to comment #8) > (In reply to comment #6) > > Indeed, mesa requires libudev v151, which provides libudev.so.0. > > > > So we can either bump the minimum required version or fall-back to > > libudev.so.0. > > > > I believe that Eric will be the judge of that. > > Is there any workaround for that? I was trying to play with libraries in > synaptic, but didn't succeed. You can either 1) use mesa commit d51dbe048a, 2) change the instance of "libudev.so.1" in loader.c to "libudev.so.0" or 3) install the libudev1 package for your distribution.
I saw this bug when i installed mesa from git on Debian Wheezy (now the stable version). Debian Whezy doesnt have libudev1, only libudev0 (at version 175). After a few hours of recompiling and hair pulling i found a very simple workaround: symlinking "libudev.so.0" to "libudev.so.1".
commit 63546b8e3d217d81a67f6f291fab48b3f381a9ca Author: Eric Anholt <eric@anholt.net> Date: Thu Jan 30 10:30:57 2014 -0800 dri: Also support the loader with libudev.so.0.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.