I'm working on porting my game to Linux, which I don't have a ton of experience with...

I'm working on porting my game to Linux, which I don't have a ton of experience with, and I'm running into an error I don't quite know how to deal with.

I am using Unity (inb4meme) and the build is running fine on my ElementaryOS installation, but I also have the Unity editor stuff installed on there. My tester is using Kubuntu (latest) and has none of the Unity editor stuff installed.

The following error is generated in the log:

Fallback handler could not load library /home/USERNAME/.local/share/Steam/steamapps/common/GAMENAME/game_Data/Mono/x86_64/libudev.so


When he runs a command to see if libudev is installed it says libudev.so.1 is installed, yet the game still errors?

I've looked around the internet for libudev.so to include in my build, but I can only seem to find things like libudev.so.0 and libudev.so.1

Does anyone have any insight into this?

Other urls found in this thread:

packages.ubuntu.com/trusty/amd64/libudev-dev/filelist
tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
github.com/ValveSoftware/steam-runtime
twitter.com/SFWRedditGifs

Installed, sure, but where? Can te loader find it in its path?

I don't have the path on me at the moment, but it is in his system folders somewhere not in the game's folder where its looking.

I've found this:

packages.ubuntu.com/trusty/amd64/libudev-dev/filelist

Which contains libudev.so, I downloaded it and extracted that file but its just an empty symlink file? And even stranger Windows doesn't let me move it from where extracted.

likely somewhere under /lib

These are the launch options available in the Steam backend, is there some way I can make the OS install libudev-dev in a run.sh file?

Don't steam games run in a chroot environment?

I honestly have no idea

If anyone with linux would like to test it out I'd be happy to give a key to them. You have to give me a way to contact you though.

Im not an expert but iirc the "linker name" file is almost always a symlink.

linker name:
ends in .so without version number , almost always a symlink.
This is the file the compiler linker at compilation time.

soname:
ends in .so.[versionNumber] , almost always a symlink. This is the actual name embedded in the ELF executable file
the loader/linker will look for this file when starting the program/doing dynamic linking.

realname:
ends in .so.[minorNumber].[releaseNumber] , the actual object file that contains the code.


linker name-> soname -> realname
libudev.so(symlink) -> libudev.so.1(symlink) -> libudev.so.1.2(symlink)

if you compile your aplication with:
[spoiler]
gcc *.c -ludev
[/spoiler]
and libudev.so links to libudev.so.1 , then the SONAME libudev.so.1 will be put on the ELF executable file.
When the loader loads your program if will look for libudev.so.1, cause libudev.so.1 links to libudev.so.1.2 it will load libudev.so.1.2 in memory.

Maybe you can make a symlink "libudev.so" that links to the real file on your /lib ( or download the .so and link it to that)?
I don't know if that is a good solution, thought.

If some user sees any mistakes in my post , please correct me. Im still learning so it would be pretty helpful for my
Also excuse my broken engrish.

I wanted to use not spoilers.
why do i always mess up everything

Just fucking kill me already

it's ok senpai
there is no need to be upset

PC requirements?

Interesting, that clears up a bit of my confusion about this naming system!

I've found some more errors higher up than the libudev error. If this means anything to anyone could you let me know?

libkmod: ERROR ../libkmod/libkmod-config.c:635 kmod_config_parse: /etc/modprobe.d/bbswitch.conf line 1: ignoring bad line starting with 'bbswitch'
modprobe: FATAL: Module nvidia-modeset not found in directory /lib/modules/4.4.0-66-generic
Assert( Assertion Failed: fatal stalled cross-thread pipe ):../common/pipes.cpp:769

ERROR: ld.so: object '/home/volnes/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.

*libudev.so(symlink) -> libudev.so.1(symlink) -> libudev.so.1.2(actual object file)

its okay user I won't judge you

it requires a decent pc, moreso a decent cpu

I'm a total fucking noob retard, but have you tried editing the
ld.so.conf file to include the path to the library and then running the ldconfig command?

the he'd have to :

* make an installer
* have installer check for libudev location
* have installer create simlink
* alternatively install libudev if not already present

right ?

That's a big negative, but I'll put it on my list of shit to try

I'm beginning to think it may actually be an issue with Steam and its overlay rather than Unity

I know pretty much nothing about deploying software and unix sysadmin,
I'm not sure if using add-hoc methods like that will be a good Idea.
If think that OP might be better asking this on stackOverflow or unix.stackexchange.

ye there probably are tools from unity to handle this shit

This maybe of some help:
tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html

so is this saying I should just put the libudev.so.0 or libudev.so.1 file and it'll find that version on the clients machine?

try upgrading steam

I already updated teh Steamworks api stuff, and the Steam client auto-updates

OP, try this:

ln -sf /lib/x86_64-linux-gnu/libudev.so.1 /lib/x86_64-linux-gnu/libudev.so.0

I know little about Steam under Linux, but I ran into this a while back :

github.com/ValveSoftware/steam-runtime

"Steam ships with a copy of the Steam Runtime and all Steam Applications are launched within the runtime environment."

Also not unimportant :

"To prevent libraries from development and build machines 'leaking' into your applications, you should build within a Steam Runtime chroot environment."