A workround for my system was to create the following symlink

ln -s /usr/lib32/dri/r600g_dri.so /usr/lib32/dri/radeon_dri.so

I guess that Star Conflict should check for the generic driver library name and not a fixed name "radeon_dri.so".

I just figured out that my system generates a "radeon_dri.so" when I enable to install the VERY old r100 driver ( http://xorg.freedesktop.org/wiki/RadeonFeature/#index1h2 - r100/r200 have no GLSL and MSAA !).
I think this is really not intended by the developers of Star Conflict!

During my research on this particular issue I found the following bug report: http://osdir.com/ml/...4/msg09269.html

From what I understood this is an issue of using mesa 10.1 (or anything containing the patches from http://patchwork.fre...rg/patch/17793/) and libudev.so.0. My base system only contains libudev.so.1, but sadly the steam runtime (in ~/.local/share/Steam) currently ships libudev.so.0. I first attempted to work around the issue by deleting the file, but steam no longer started.

I did a nasty workaround to symlink my systems libudev.so.1 to overwrite the local libudev.so.0 in the steam runtime. If you are on x86_64 (64-bit OS) do:
ln -s /usr/lib32/libudev.so.1 ~/.local/share/Steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu/libudev.so.0
If you are on i686 (32-bit OS) do:
ln -s /usr/lib/libudev.so.1 ~/.local/share/Steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu/libudev.so.0
This issue will hit more users once mesa 10.1 is more widespread, which is likely to be soon as Ubuntu 14.04 was released shipping mesa 10.1.

Egore, your comment is completely unrelated to my issue. I have no problems with udev and your symlink does not change the issue.
You should create a new bug report for that.

I think your error is an caused by the same problem. Let me try to explain why...

The reason mesa is picking radeon_dri.so is not caused by the Star Conflict or Stea developers. It happens within mesa when the MESA-LOADER (introduced in mesa 10.1) fails to identify the udev device for a devices file descriptor (e.g. /dev/dri/card0). This is show in your report: "could not create udev device for fd ..." telling me you actually have udev errors. I'm not an expert but I've been following the mesa project for 10 years now.

In my case this error was caused by building mesa against libudev.so.1 and running it against libudev.so.0. Both are very similar so that runtime linking works, but the code does not behave correct. I think this is the most common error triggering this message and I was hoping it is the same issue for you, but I might have been wrong.

My recommendation to you is to check if the path in my suggestion is the same on your system. Me/t to that you could give fglrx (ATIs official driver) a try which has nothing in common with mesa and might work for that reason.

If I create your symlink as you wrote, I still see the very same error:

Game update: AppID 212070 "Star Conflict", ProcID 4268, IP 0.0.0.0:0
ERROR: ld.so: object '/home/eod/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object '/home/eod/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded: ignored.
/home/mysteam/SteamApps/common/star conflict/StarConflict: /usr/lib32/libcurl.so.4: no version information available (required by /home/mysteam/SteamApps/common/star conflict/StarConflict)
/home/mysteam/SteamApps/common/star conflict/StarConflict: /usr/lib32/libcrypto.so.1.0.0: no version information available (required by /home/mysteam/SteamApps/common/star conflict/StarConflict)
Setting breakpad minidump AppID = 212070
Steam_SetMinidumpSteamID:  Caching Steam ID:  76561198054163081 [API loaded no]
libGL error: MESA-LOADER: could not create udev device for fd 762
libGL error: dlopen /usr/lib32/dri/radeon_dri.so failed (/usr/lib32/dri/radeon_dri.so: cannot open shared object file: No such file or directory)
libGL error: unable to load driver: radeon_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: radeon
Game removed: AppID 212070 "Star Conflict", ProcID 4269

The only workaround I found is the symlink to r600g_dri.so.

@egore
"fglrx (ATIs official driver)" maybe official, but it is illegal. Linus T. tolerates them by not suing them.
On linux, closed source drivers, user space or kernel space must be opened.
Above the legal plane, you have the ethics plane: Open source people are looking for a 100% OS with optimal code. Video games are ok to be closed since they are "normal" programs.
The proper course of action is to favor the open source driver, sometimes it means not playing a game till mesa catches up with the missing features or till the game coders have added mesa support.

EoD, I think egore is right. You suffer from the lookup function within MESA taking the wrong udev lookup. Basically both libudev.so.0 and .1 are linked against and loaded with steam, unfortunately the old .0 being first. And iirc symbol lookup does take the first function symbol, thus the old libudevs udev_device_new_from_devnum(), resulting in driver lookup failure. You can check this by simply running steam like this:

env LD_PRELOAD="/usr/lib32/libudev.so.1" steam

That preloads the new libudev, whose symbols are used then. Works for me, without any other symlinking.

The steam runtime should not use libudev as a system dependency:
you have had many libudev forks since Poettering from redhat forced the
"official" libudev into systemd (that is VERY bad).
Better not to go more that libudev.so.0 (before systemd nasty
trick).
long term: manage the uevents directly, not going trough udev.
But to be sure no conflict will arise with a system installed
udev is to check if a netlink socket for the kernel uevents does
get the uevent even with a udevd running.