Is there some particular reason why you link specifically against libudev.so.0? This lib is like one year old, so you probably should consider switching to libudev.so.1. Or better yet, to move to plain libudev.so, as I doubt you need some version-specific functionality.
I have to admit I'm curious why udev is linked at all. What does PA want with the device management subsystem?
I've investigated this a bit, and it appears to be coming from Coherent. We've been in contact with them, and they're working on a fix.
You could always create a wrapper script that selects the appropriate library and uses LD_PRELOAD to specify that it should be loaded before PA gets put into memory. Edit: (the non-obvious bonus here being that it also solves the issue where it can be in different places, such as /lib/x86_64-linux-gnu/ instead of /lib)
LD_PRELOAD won't work, because it's not "I can't find it because it's not in LD_LIBRARY_PATH" kind of problem, but rather "I can't find it because it doesn't exist". That's also why the path issue is irrelevant. It doesn't link to "/lib/libudev.so.0", it links just to "libudev.so.0" Code: ldd ./host/CoherentUI_Host <...> libudev.so.0 => not found
they could, or they could find out why some UI is linking against a low-level device interface lib when xorg should be providing enough abstraction for i/o. It would be like solitaire wanting to know what hardware you have. i can't think of any reason why it should (maybe it was at some point a more reliable means for sound detection or gfx) and it is good that Uber are looking into it.
BTW, I've looked closer at "ldd ./host/CoherentUI_Host" output, and found some interesting features. First of all, all of the libraries that one was linked against were versioned. Sometimes it can make sense, like in case of libstdc++.so.6, but I'm pretty sure that most of these versions can be safely dropped. Next, I found a link to libXinerama.so.1. I'm not an expert in X, but I believe the Xinerama support was obsoleted in favour of XRandR a couple of years ago. So it's a very questionable decision to still use it. And finally, the link to libsystemd-daemon.so.0. It raises a whole bunch of questions, starting from "why do the game care about my init system lib" and to "what should do people without systemd?" I'm actually surprised it runs under Ubuntu, as it doesn't (and never will) have systemd. So yes, Uber, that one definitely needs checking.
I can assure you that if you LD_PRELOAD the _existing_ library that the application won't care that the one it expects doesn't exist. The loader will establish that all of the symbols it requires have been met by the LD_PRELOADed library and it won't even attempt to load the expected library.
Nope Code: morse@morseworkbook ~/.local/share/Steam/SteamApps/common/Planetary Annihilation $ LD_PRELOAD="/lib/libudev.so.1.2.1" ./PA [20:08:09.434] INFO Log file /home/morse/.local/Uber Entertainment/Planetary Annihilation/log/PA-20-08-09.433.txt opened [20:08:09.529] INFO GL_VENDOR: X.Org [20:08:09.529] INFO GL_RENDERER: Gallium 0.4 on AMD TURKS [20:08:09.530] INFO GL_VERSION: 3.0 Mesa 9.2.0-devel (git-ce1f851) [20:08:09.530] INFO GL_SHADING_LANGUAGE_VERSION: 1.30 [20:08:12.114] INFO Configure, 1280 by 720 [20:08:12.114] INFO build version 49595 [20:08:12.114] INFO Coherent content root: "file:///home/morse/.local/share/Steam/SteamApps/common/Planetary Annihilation/media/ui/" [20:08:12.114] INFO Coherent host dir: "/\x00h\x00o\x00m\x00e\x00/\x00m\x00o\x00r\x00s\x00e\x00/\x00.\x00l\x00o\x00c\x00a\x00l\x00/\x00s\x00h\x00a\x00r\x00e\x00/\x00S\x00t\x00e\x00a\x00m\x00/\x00S\x00t\x00e\x00a\x00m\x00A\x00p\x00p\x00s\x00/\x00c\x00o\x00m\x00m\x00o\x00n\x00/\x00P\x00l\x00a\x00n\x00e\x00t\x00a\x00r\x00y\x00 \x00A\x00n\x00n\x00i\x00h\x00i\x00l\x00a\x00t\x00i\x00o\x00n\x00/\x00h\x00o\x00s\x00t\x00/\x00" [20:08:12.115] INFO Coherent local store: "/\x00h\x00o\x00m\x00e\x00/\x00m\x00o\x00r\x00s\x00e\x00/\x00.\x00l\x00o\x00c\x00a\x00l\x00/\x00U\x00b\x00e\x00r\x00 \x00E\x00n\x00t\x00e\x00r\x00t\x00a\x00i\x00n\x00m\x00e\x00n\x00t\x00/\x00P\x00l\x00a\x00n\x00e\x00t\x00a\x00r\x00y\x00 \x00A\x00n\x00n\x00i\x00h\x00i\x00l\x00a\x00t\x00i\x00o\x00n\x00/\x00l\x00o\x00c\x00a\x00l\x00s\x00t\x00o\x00r\x00e\x00" [20:08:12.198] INFO setupViewportStack : 1 /home/morse/.local/share/Steam/SteamApps/common/Planetary Annihilation/host/CoherentUI_Host: error while loading shared libraries: libudev.so.0: cannot open shared object file: No such file or directory Edit: I know that it should, but for some reason - it doesn't.
Run "file /lib/libudev.so.1.2.1" and make sure it says that's a 64-bit ELF library. Edit: Also, if they're spawning that process and not copying the environment then the preload won't apply. You'd need to move ${HOME}/.local/share/Steam/SteamApps/common/Planetary\ Annihilation/host/CoherentUI_Host to another spot and make that a script that applies the LD_PRELOAD.
This appears to be similar to an issue Chrome was having a few revs ago. Basically, if you upgraded from Ubuntu 12.04/12.10 to 13.04, you should still have libudev0. New installs don't. This suggestion appears to work: http://linuxg.net/how-to-fix-dependency ... ntu-13-04/ TL;DR, this looks like a pretty reliable fix: Code: wget -c www.mirrorservice.org/sites/archive.ubuntu.com/ubuntu//pool/main/u/udev/libudev0_175-0ubuntu13_amd64.deb sudo dpkg -i libudev0*.deb As mentioned, Coherent is working on a more permanent fix. (The information I've been unable to determine is why Ubuntu chose deprecate libudev0 in the first place...)
It doesn't link to libsystemd-daemon.so.0, its because you use sysd and your udev links against sysd SO wih it linking to udev it also appears to have a link into sysd on your machine.
Hm, I always thought that ldd shows only the direct dependencies, but may be you're right. That will also explain xinerama.
Digging through all of the commands and IO, I found this interesting fact, PA is linking against the libudev files provided by the Steam launcher, not the ones directly installed on your system. This library as provided by Steam is 32 bit and that may be causing a lot of problems for people.
Anyway after playing a bit with PA I found a simple fix for you. Extract libudev.so.0 from that deb package and include it in Steam distribution. Put it in /home/user/.local/share/Steam/SteamApps/common/Planetary Annihilation and it works This way we don't need any workarounds. This is kinda similar to what Chrome did. They ship the libudev.so.0 with the installer Edit-> It isn't about Ubuntu and deprecation. It is about the fact that udev devs broke abi compatibility. Edit2->Relevant comment https://github.com/Kodowa/Light-Table-P ... t-18040920 the difference is that you don't need to symlink it to /usr/lib as Steam takes care of library path. On the other hand in your own launcher you will need to take care of that. You could wrap the PA executable in script and run it with command: "LD_LIBRARY_PATH=_pa_directory_ ./PA" or something like that, you should get the idea.
I am running on LinuxMint 15 64 bit. These instructions don't work for me but I found what did. Code: cd ~/.local/share/Steam/SteamApps/common/Planetary Annihilation wget -c www.mirrorservice.org/sites/archive.ubuntu.com/ubuntu//pool/main/u/udev/libudev0_175-0ubuntu13_amd64.deb dpkg -x libudev0_175-0ubuntu13_amd64.deb libudev.so.0.13.0 cp libudev.so.0.13.0/lib/x86_64-linux-gnu/libudev.so.0 ./host/ Seemed to work fine after that.
you can use readelf -d to list direct dependencies. Code: readelf -d host/CoherentUI_Host Dynamic section at offset 0x3eca5f0 contains 51 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0] 0x0000000000000001 (NEEDED) Shared library: [librt.so.1] 0x0000000000000001 (NEEDED) Shared library: [libgtk-x11-2.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [libgobject-2.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [libX11.so.6] 0x0000000000000001 (NEEDED) Shared library: [libcairo.so.2] 0x0000000000000001 (NEEDED) Shared library: [libdl.so.2] 0x0000000000000001 (NEEDED) Shared library: [libfontconfig.so.1] 0x0000000000000001 (NEEDED) Shared library: [libfreetype.so.6] 0x0000000000000001 (NEEDED) Shared library: [libgconf-2.so.4] 0x0000000000000001 (NEEDED) Shared library: [libgdk-x11-2.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [libgdk_pixbuf-2.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [libglib-2.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [libnspr4.so] 0x0000000000000001 (NEEDED) Shared library: [libpango-1.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [libpangocairo-1.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [libsmime3.so] 0x0000000000000001 (NEEDED) Shared library: [libudev.so.0] 0x0000000000000001 (NEEDED) Shared library: [libXcomposite.so.1] 0x0000000000000001 (NEEDED) Shared library: [libXext.so.6] 0x0000000000000001 (NEEDED) Shared library: [libXfixes.so.3] 0x0000000000000001 (NEEDED) Shared library: [libXrender.so.1] 0x0000000000000001 (NEEDED) Shared library: [libnss3.so] 0x0000000000000001 (NEEDED) Shared library: [libnssutil3.so] 0x0000000000000001 (NEEDED) Shared library: [libXrandr.so.2] 0x0000000000000001 (NEEDED) Shared library: [libasound.so.2] 0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6] 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] 0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x000000000000000c (INIT) 0x424598 0x000000000000000d (FINI) 0x2bd69bc 0x0000000000000019 (INIT_ARRAY) 0x4282aa0 0x000000000000001b (INIT_ARRAYSZ) 672 (bytes) 0x000000006ffffef5 (GNU_HASH) 0x4002d0 0x0000000000000005 (STRTAB) 0x40d770 0x0000000000000006 (SYMTAB) 0x401680 0x000000000000000a (STRSZ) 48046 (bytes) 0x000000000000000b (SYMENT) 24 (bytes) 0x0000000000000015 (DEBUG) 0x0 0x0000000000000003 (PLTGOT) 0x44d2fe8 0x0000000000000002 (PLTRELSZ) 34608 (bytes) 0x0000000000000014 (PLTREL) RELA 0x0000000000000017 (JMPREL) 0x41be68 0x0000000000000007 (RELA) 0x41a6f8 0x0000000000000008 (RELASZ) 6000 (bytes) 0x0000000000000009 (RELAENT) 24 (bytes) 0x000000006ffffffe (VERNEED) 0x41a338 0x000000006fffffff (VERNEEDNUM) 11 0x000000006ffffff0 (VERSYM) 0x41931e 0x0000000000000000 (NULL) 0x0
Ok, we got what should be a fix from Coherent. It should be in the next build. (I think. Kind of depends on when the next build gets built.) We replaced the UI host with a script that runs the host, but sets up a symlink to libudev.so.1 if necessary, similar to the behavior of chrome.
