Game can’t start on Fedora 18 due to a missing libudev.so.0 library …
This does not exist on F18 (being libudev.so.1 on the current release) so either needs to be statically compiled or recompilied to support the current release alongside the last …
Interestingly enough ldd showed dependencies on both libudev.so.- and libudev.so.1 ?
I don’t have the 1.3.2 update on my purchase link yet but don’t see this issue mentioned on there…
Symbolically linking libudev.so.1 to libudev.so.0 allowed it to fire up - don’t know the consequences of doing this yet though…
how did you make it work? I have also fedora 18 but creating symlink from /usr/lib/libudev.so.0 to /usr/lib/libudev.so.1 doesn’t work for me. I’m still getting dependency error: libudev.so.0 is needed by gamedevtycoon-1.3.1-1.i386.
Make sure you have the 32bit libudev libraries in as well …
You need to symlink to those not the 64bit ones…
yum install systemd-libs-197-1.fc18.2.i686 would be the current ones I think - but if you haven’t updated recently you will need to match the version of the 32bit ones to whatever 64bit ones you already have installed.
Symlinking like crazy in your file system could lead to unexpected issues down the line if the files get modified by other processes, like your package manager. Something in the form of this might work as a less elegant (but also less harmful) solution for running the game for you:
LD_PRELOAD=</path/to/libudev.0.so> gamedevtycoon
I would like a native 64-bit version of the game, though. I ended up installing a heap of 32-bit versions of libraries I already had just to get to the point where libudev was the issue.
EDIT: Noticed that the parameter to LD_PRELOAD was being filtered by the forum
Hi,
tellus is right, I would strongly advice against symlinking libraries from point a to point b in your system.
Actually, I could get the game running quite easily by simply adding it to steam (“add non steam application…”) on Fedora 18, since steams bundles its own version of libudev which seems to be compatible with the game. I think this works because libudev is already loaded in the address space of steam and since steam executes game tycoon as an child process, it uses the steam bundled version.
I think this is a more elegant solution than tinkering with old packages or using some unclean symlink solution.
Most package managers actually do a bit of library symlinking of their own to keep things running. The numbers after libudev.so are essentially a version number. Before the days of robust package managers or in some more-DIY distributions, it was a pretty common practice to solve this through symlinks rather than having multiple versions of a library on disk.
GameDevTycoon is searching your library path for libudev.so.0 and not finding it (since you have a much newer version of libudev installed). I can verify this is still happening in the current 1.3.9 x64 release since I installed the game last night, so I thought I’d chime in.
If you take a look in the gamedevtycoon launch script, they have some code that pulls the location the game data lives in and prepends your library path with that directory (and if it exists, the /lib subdirectory under it) to force it to use the GHG library versions if they’re present.
if [[ -n "$LD_LIBRARY_PATH" ]]; then
LD_LIBRARY_PATH="$HERE:$HERE/lib:$LD_LIBRARY_PATH"
else
LD_LIBRARY_PATH="$HERE:$HERE/lib"
fi
export LD_LIBRARY_PATH
If you don’t want to leave a symlink to libudev.so.0 laying around your base /lib directory, you can just make a lib directory and symlink there:
On Gentoo at least, the package manager is using its own symlink to create libudev.so.1 so that as I perform minor updates to libudev I don’t have to worry about things that depend on libudev.so.1 breaking with every update:
