It should be noted that you seem to be running a 32-bit Linux.
On 64-bit I can only reproduce with preloading /usr/lib32/libstdc++.so.6

I'm running a x86_64 Debian Sid with both i386 and x86_64 libraries installed. But it is likely that the $LIB part is converted to lib/i386-linux-gnu inside steam when starting the game.

Also note that I do no add the LD_PRELOAD option when I run the game manually.

if that'd be the case you'd have the path /usr/lib/i386-linux-gnu/libstdc++.so.6, which is likely not to exist. Also the executable has no power about the LD_PRELOAD and the LIB -- these are evaluated before.

Can you post the output of echo $LIB? I suppose for some reason it's set to lib32.

What I said this morning was just out of my head, so I will need to confirm everything when I arrive home.

Please take into account that the contents of $LD_PRELOAD are defined between single quotes and, as such, are only evaluated when executed. That definition was taken from here and it refers to the following section of man 8 ld.so:

   Rpath token expansion
       ld.so understands certain strings in an rpath specification (DT_RPATH or DT_RUNPATH); those strings are substituted as follows

[...]

       $LIB (or equivalently ${LIB})
              This expands to lib or lib64 depending on the architecture (e.g., on x86-64, it expands to lib64 and on x86-32, it expands to lib).

Follow this link to learn more about Debian Multiarch. In particular, the section Multiarch and multilib of Multiarch LibraryPath Overview seems to confirm the existence of the path I mentioned before. But again, I'll need to confirm this at home.

I can confirm it to be in the manpages but I for me

$ env LD_PRELOAD='/usr/$LIB/libstdc++.so.6' steam

and

$ env LD_PRELOAD='/usr/lib64/libstdc++.so.6' steam

give different results, that is the former crashes, the latter does not. I suppose it's expanding depending on the architecture of the binary rather than of the OS (good to know, didn't know that).

Anyway, it thus expands to lib32 because steam is using 32-bit. So all in all: Civ V crashes when preloading the /usr/lib32/libstdc++.so.
Possibly it'd work if you'd be using LD_PRELOAD=~/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu/libstdc++.so %command% in the launch options of the game?

This'd revert the former LD_PRELOAD but maybe it doesn't revert the fix for your drivers.

I can give it a try tonight, but I think I've been down that road before and if I remember correctly Steam crashes because of the collision with the radeon open source drivers. In fact, that's why I had to add that LD_PRELOAD setting in the first place: I wasn't even able to start steam if it wasn't there!

Did you read the final paragraph of this text? Do you think such an approach, together with this $LIB variable would help to overcome the many issues Steam is having with the open vs closed source video drivers? (I know there's an issue about this here in github, but I can't find it)

Well, I'm not sure if the workaround is only needed fir steam or for the games too.
If only for steam, the double LD_PRELOAD should work, since the latter one only overrides the libs for CivV -- and not for steam.

I haven't thoroughly read it yet since being on mobile but it could be the key.

The game fails to start even with that launch option.

Some more details when calling the game from command line.

$ env LD_PRELOAD=~/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu/libstdc++.so.6 ./Civ5XP 
./Civ5XP: Symbol `_ZTVN10__cxxabiv120__si_class_type_infoE' has different size in shared object, consider re-linking
./Civ5XP: Symbol `_ZTVN10__cxxabiv117__class_type_infoE' has different size in shared object, consider re-linking
./Civ5XP: Symbol `_ZTVN10__cxxabiv121__vmi_class_type_infoE' has different size in shared object, consider re-linking
libGL error: unable to load driver: radeonsi_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: radeonsi
libGL error: unable to load driver: radeonsi_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: radeonsi
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  156 (GLX)
  Minor opcode of failed request:  3 (X_GLXCreateContext)
  Value in failed request:  0x0
  Serial number of failed request:  99
  Current serial number in output stream:  100
$ env LD_PRELOAD='/usr/$LIB/libstdc++.so.6' ./Civ5XP 
./Civ5XP: Symbol `_ZTVN10__cxxabiv120__si_class_type_infoE' has different size in shared object, consider re-linking
./Civ5XP: Symbol `_ZTVN10__cxxabiv117__class_type_infoE' has different size in shared object, consider re-linking
./Civ5XP: Symbol `_ZTVN10__cxxabiv121__vmi_class_type_infoE' has different size in shared object, consider re-linking
Segmentation fault
$ ldd Civ5XP 
    linux-gate.so.1 (0xf7713000)
    libcrypto.so.1.0.0 => ./libcrypto.so.1.0.0 (0xf7564000)
    libMiles.so => ./libMiles.so (0xf74dc000)
    libtbb.so.2 => ./libtbb.so.2 (0xf74aa000)
    libssl.so.1.0.0 => ./libssl.so.1.0.0 (0xf7454000)
    libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xf72d9000)
    libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf72bc000)
    librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xf72b3000)
    libc++.so.1 => ./libc++.so.1 (0xf7208000)
    libcxxrt.so => ./libcxxrt.so (0xf71e9000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf706c000)
    /lib/ld-linux.so.2 (0x565fe000)
    libsteam_api.so => ./libsteam_api.so (0xf705c000)
    libGL.so.1 => /usr/lib/i386-linux-gnu/libGL.so.1 (0xf6fed000)
    libopenal.so.1 => ./libopenal.so.1 (0xf6fa2000)
    libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf6f9d000)
    libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf6f51000)
    libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf6f34000)
    libuuid.so.1 => ./libuuid.so.1 (0xf6f2e000)
    libiconv.so.2 => ./libiconv.so.2 (0xf6e49000)
    libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xf6e2c000)
    libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xf6cbc000)
    libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xf6c96000)
    libexpat.so.1 => /lib/i386-linux-gnu/libexpat.so.1 (0xf6c6d000)
    libxcb-dri3.so.0 => /usr/lib/i386-linux-gnu/libxcb-dri3.so.0 (0xf6c68000)
    libxcb-present.so.0 => /usr/lib/i386-linux-gnu/libxcb-present.so.0 (0xf6c64000)
    libxcb-randr.so.0 => /usr/lib/i386-linux-gnu/libxcb-randr.so.0 (0xf6c54000)
    libxcb-xfixes.so.0 => /usr/lib/i386-linux-gnu/libxcb-xfixes.so.0 (0xf6c4b000)
    libxcb-render.so.0 => /usr/lib/i386-linux-gnu/libxcb-render.so.0 (0xf6c40000)
    libxcb-shape.so.0 => /usr/lib/i386-linux-gnu/libxcb-shape.so.0 (0xf6c3a000)
    libxcb-sync.so.1 => /usr/lib/i386-linux-gnu/libxcb-sync.so.1 (0xf6c32000)
    libxshmfence.so.1 => /usr/lib/i386-linux-gnu/libxshmfence.so.1 (0xf6c2f000)
    libglapi.so.0 => /usr/lib/i386-linux-gnu/libglapi.so.0 (0xf6c13000)
    libXext.so.6 => /usr/lib/i386-linux-gnu/libXext.so.6 (0xf6bfe000)
    libXdamage.so.1 => /usr/lib/i386-linux-gnu/libXdamage.so.1 (0xf6bf9000)
    libXfixes.so.3 => /usr/lib/i386-linux-gnu/libXfixes.so.3 (0xf6bf2000)
    libX11-xcb.so.1 => /usr/lib/i386-linux-gnu/libX11-xcb.so.1 (0xf6bef000)
    libxcb-glx.so.0 => /usr/lib/i386-linux-gnu/libxcb-glx.so.0 (0xf6bd4000)
    libxcb-dri2.so.0 => /usr/lib/i386-linux-gnu/libxcb-dri2.so.0 (0xf6bce000)
    libXxf86vm.so.1 => /usr/lib/i386-linux-gnu/libXxf86vm.so.1 (0xf6bc6000)
    libdrm.so.2 => /usr/lib/i386-linux-gnu/libdrm.so.2 (0xf6bb4000)
    libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xf6bb0000)
    libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xf6ba9000)
$ ./Civ5XP 
GUID Assets\dlc\dlc_01\mongol.civ5pkg 7a036b7fb9a80e8dea7b73fb58c5a288
GUID Assets\dlc\dlc_sp_maps_2\dlc_sp_maps_2.civ5pkg 16a61e7a2a7bb4bc2d1f677b5bb58ff4
GUID Assets\dlc\dlc_sp_maps_3\dlc_sp_maps_3.civ5pkg 1954db58e0a60b018969c49440fa01ef
GUID Assets\dlc\expansion\expansion1.civ5pkg 8bc30c58378345cb0911c5848926f1ff
GUID Assets\dlc\shared\upgrade1.civ5pkg e818fa28902977b42ee5e3426f5112e6
[S_API FAIL] SteamAPI_Init() failed; no appID found.
Either launch the game from Steam, or put the file steam_appid.txt containing the correct appID in your game folder.
AL lib: pulseaudio.c:612: Context did not connect: Access denied

Only on the last execution does the game start. Funny enough, when using the $LIB trick the game fails to start! Out of curiosity I decided to use the same trick with Monaco to see what happened. This is the result:

$ ldd Monaco.bin.x86 
    linux-gate.so.1 (0xf77d6000)
    libsteam_api.so => /home/vhda/.local/share/Steam/SteamApps/common/Monaco/./lib/libsteam_api.so (0xf77be000)
    libfmodex-4.44.20.so => /home/vhda/.local/share/Steam/SteamApps/common/Monaco/./lib/libfmodex-4.44.20.so (0xf7638000)
    libSDL2-2.0.so.0 => /home/vhda/.local/share/Steam/SteamApps/common/Monaco/./lib/libSDL2-2.0.so.0 (0xf7550000)
    libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf750a000)
    libGL.so.1 => /usr/lib/i386-linux-gnu/libGL.so.1 (0xf749b000)
    libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xf747e000)
    libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xf730e000)
    libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf72c1000)
    libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf72a4000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7127000)
    libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf7122000)
    /lib/ld-linux.so.2 (0x5663d000)
    librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xf7119000)
    libexpat.so.1 => /lib/i386-linux-gnu/libexpat.so.1 (0xf70ef000)
    libxcb-dri3.so.0 => /usr/lib/i386-linux-gnu/libxcb-dri3.so.0 (0xf70eb000)
    libxcb-present.so.0 => /usr/lib/i386-linux-gnu/libxcb-present.so.0 (0xf70e7000)
    libxcb-randr.so.0 => /usr/lib/i386-linux-gnu/libxcb-randr.so.0 (0xf70d7000)
    libxcb-xfixes.so.0 => /usr/lib/i386-linux-gnu/libxcb-xfixes.so.0 (0xf70ce000)
    libxcb-render.so.0 => /usr/lib/i386-linux-gnu/libxcb-render.so.0 (0xf70c2000)
    libxcb-shape.so.0 => /usr/lib/i386-linux-gnu/libxcb-shape.so.0 (0xf70bd000)
    libxcb-sync.so.1 => /usr/lib/i386-linux-gnu/libxcb-sync.so.1 (0xf70b5000)
    libxshmfence.so.1 => /usr/lib/i386-linux-gnu/libxshmfence.so.1 (0xf70b2000)
    libglapi.so.0 => /usr/lib/i386-linux-gnu/libglapi.so.0 (0xf7096000)
    libXext.so.6 => /usr/lib/i386-linux-gnu/libXext.so.6 (0xf7080000)
    libXdamage.so.1 => /usr/lib/i386-linux-gnu/libXdamage.so.1 (0xf707c000)
    libXfixes.so.3 => /usr/lib/i386-linux-gnu/libXfixes.so.3 (0xf7075000)
    libX11-xcb.so.1 => /usr/lib/i386-linux-gnu/libX11-xcb.so.1 (0xf7072000)
    libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xf6f20000)
    libxcb-glx.so.0 => /usr/lib/i386-linux-gnu/libxcb-glx.so.0 (0xf6f04000)
    libxcb-dri2.so.0 => /usr/lib/i386-linux-gnu/libxcb-dri2.so.0 (0xf6efe000)
    libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xf6ed8000)
    libXxf86vm.so.1 => /usr/lib/i386-linux-gnu/libXxf86vm.so.1 (0xf6ed1000)
    libdrm.so.2 => /usr/lib/i386-linux-gnu/libdrm.so.2 (0xf6ebf000)
    libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xf6eba000)
    libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xf6eb3000)
$ env LD_PRELOAD='/usr/$LIB/libstdc++.so.6' ./Monaco.bin.x86 
[S_API FAIL] SteamAPI_Init() failed; Sys_LoadModule failed to load: /home/vhda/.steam/bin32/steamclient.so
[S_API FAIL] SteamAPI_Init() failed; unable to locate a running instance of Steam, or a local steamclient.dll.
[0] ===================================================================================================

And the game ran perfectly. Is it possible that Civilization 5 is linked in some strange way that ignores the $LIB setting? Take into account that both ldd executions show that the two games are linked to similar libs (but I did not compare all dependencies).

This seems to work here:

launchcivv.bash:

#!/bin/bash
export LD_PRELOAD=./libcxxrt.so:/usr/lib32/libstdc++.so.6
"$@" 2>&1

Run it as /path/to/launchcivv.bash %command%.

Apparently these symbols are "weak" (in their libc++.so.1) or even completely undefined (in /usr/lib32/libstdc++.so.6). The libcxxrt.so.1 provides definitions and has to be loaded before the others are loaded -- at least this seems to work for me.

Setting the following launch options is enough to make the game launch from Steam:

LD_PRELOAD='./libcxxrt.so:/usr/$LIB/libstdc++.so.6' %command%

Is this going to be the "official" solution, or will the game be fixed (eventually)?

BTW, how did you identify libcxxrt.so?

Glad it helped!
I'm no Valve employee so I have no idea :-)

But I doubt that there'll be a chane as using LD_PRELOAD is not the way it's supposed to be run anyway ^^
Also I've got no idea what they should do, as long as they need to ship that library.
The problem is that the order of loading libraries matters and it's configured correctly... but we override it.
There's few things they could possibly change:

• try not using the libcxxrt.so
• static linkage (no good idea imho)
• somehow try to force different orders (probably complicated)

And of course Valve could try fixing their issues with opensource drivers ^^

The hint was the different size for the symbols. So I gathered information:

• nm libfoo.so gives you all exported symbols, so I grep-ed these for one of the "problematic" ones.
  • nm provides info on what type the symbol is of (V for weak, U for undefined, etc.); I noticed that they were U/V for our candidates
• I ran it in a working environment and in the non-working ine through gdb and looked at the order in which the libraries are loaded via info shared, and played around with some other stuff which didn't help though ^^
  • I noticed that there were also libc++ and libcxxrt (CXX is often used instead of C++ since CPP is also an acronym of the C preprocesso) in the game dir. As these are shipped they were no doubt relevant. So I checked these via nm and saw that these symbols were defined in the libcxxrt... last check via gdb: Yes, libcxxrt is by default loaded BEFORE the other stdc++/c++ libs. So I tried that :-)

Good catch!

Thank you very much for your help on this, you were essential to discover the root of the problem. And thanks also for taking the time to explain your debugging process, it might help me in the future.

Sure, no problem! Glad I could help :)

I had a similar issue with Borderlands 2. I removed the libstdc++ from the steam runtime and it works fine, causing the game to load as normal.

It seems the new library is backwards compatable with binaries linked with the old library, but the old library is not forwards compatable with binaries linked against the new library.

Static linking causes libstdc++ patches to not properly load, as seems to be the case for several games.

Valve should really switch to the new libstdc++ version shipped with the newer GCC version, or just not ship libstdc++ with Steam Runtime. Shipping the newer version is safer, but higher maintainance, shipping no libstdc++ could create future pitfalls, but is lower maintanance. I'd recommend shipping no libstdc++ for now, and start shipping the latest new compatible libstdc++ version if they run into issues in the future. (i.e. They should have a patch ready for if it fails.)

Additionally, they should move to building the Steam Runtime based on a SteamOS instead of the no-longer-supported Ubuntu 12.04

I've just tried getting back to Civ5 after a long out period. Forgot all about not being compatible with the open-source drivers (back in a day when it didn't support newer opengl).

Now I'm using the LD preload workaround, as per mentioned in the archwiki. The game doesn't open, though it works if opened directly. Also tried LD_PRELOAD='./libcxxrt.so:/usr/$LIB/libstdc++.so.6' %command% from above, directly as a game launch options and still doesn't work.

I'm still using $LIB parameter though, is this required to be changed? Is it safe to do so?

Yes, Civ 5 (as well as Borderlands 2, Borderlands The Pre-Sequel and
several other games) has an issue with that. If you read earlier in this
thread.

You need to, instead, remove the incompatible libstdc++ file from the steam
runtime directories so it defaults to the system copy.

You need to make sure you have the 32bit libstdc++ installed for some games.

On Tue, Aug 16, 2016 at 8:40 PM, Guilherme Furst [email protected]
wrote:

I've just tried getting back to Civ5 after a long out period. Forgot all
about not being compatible with the open-source drivers (back in a day when
it didn't support newer opengl).

Now I'm using the LD preload workaround, as per mentioned in the archwiki.
The game doesn't open, though it works if opened directly. Also tried
LD_PRELOAD='./libcxxrt.so:/usr/$LIB/libstdc++.so.6' %command% from above,
directly as a game launch options and still doesn't work.

I'm still using $LIB parameter though, is this required to be changed? Is
it safe to do so?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/4379#issuecomment-240281988,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADBV6XxGDpGVTK-6xsjKueeAyldwpi2Cks5qglhqgaJpZM4H7Rcb
.

But the question is... the LD preload method came about simply because removing those files isn't a really clean solution, its risky to mess with a program files and still steam will keep putting them back, so its not permanent.

So how can you pass the preloaded libraries properly so even child processes use them? My assumption was that they already used them in the first place. How come several of the other games worked well if using the steam runtime libs?

@Gfurst I'm running steam on laptop (using primusrun on archlinux) and suffered the same problem heavily. After a long time of resolve, this setup solved my problem:

I ran steam with this script, which will solve my libgl error: unable to load driver xxx problem with steam runtime:

#!/bin/bash
export LD_PRELOAD='/usr/$LIB/libstdc++.so.6 /usr/$LIB/libgcc_s.so.1 /usr/$LIB/libxcb.so.1 /usr/$LIB/libgpg-error.so'
export STEAM_FRAME_FORCE_CLOSE=1

exec /usr/bin/steam "$@"

For normal games, which doesn't need external graphic card, it just works, without any preload.

For Civil 5, borderlands 2, and many other games which requires nvidia graphic card, I used this run command, which will solve both libgl error: unable to load driver xxx and Symbol xxx has different size in shared object:

LD_PRELOAD='/usr/$LIB/libgcc_s.so.1 /usr/$LIB/libxcb.so.1 /usr/$LIB/libgpg-error.so ./libcxxrt.so /usr/lib32/libstdc++.so.6' primusrun %command%

I don't know if it works in your case, but hope it helps.

@bookletchoir alright, I'll try it out
your first script is exactly like mine, except the FRAME_FORCE_CLOSE part, what is that for?

so you need to preload all the same libraries for each single game, which is a bit odd, so either the preload is not passing on to child processes, or the $LIB is expanding to only 32 bit libs, like mentioned above in the thread.

@Gfurst it's nothing important, STEAM_FRAME_FORCE_CLOSE will close the client on pressing "close" button instead of minimize to tray.

And well, you can use the second preload to launch steam, and run games normally without any futher preload. I forgot to mention I was just doing it separately to suppress any - either harmful or harmless - wrong elf class msg from the client.

tldr: you can launch steam with

export LD_PRELOAD='/usr/$LIB/libgcc_s.so.1 /usr/$LIB/libxcb.so.1 /usr/$LIB/libgpg-error.so ./libcxxrt.so /usr/lib32/libstdc++.so.6'
exec /usr/bin/steam "$@"

and dont have to preload anything per game.

Also tried LD_PRELOAD='./libcxxrt.so:/usr/$LIB/libstdc++.so.6' %command% from above, directly as a game launch options and still doesn't work.

It could be because recently Aspyr shipped an update that seemingly changed a bunch of the library-dependencies (they also added some missing libs).

I don't get it, libcxxrt.so did nothing for me. However having a complete LD preload with all essential libs the game does work.... However the preload isn't passed from steam itself to its child processes, which really make this a non permanent solution, since you need to check for each game if the custom launch is needed.

For me now, what is working is disabling the steam runtime completely, I had to compile and download a bunch of extra stuff to make this work, more or less easy on Arch Aur.

@Gfurst Pretty late reply but in case you haven't known, steam-native-runtime is now on archlinux's official repo.

If you run into some problems, check this topic and probably this post. In my case, everything works perfectly without any ld_preload.

I confirm that the game no longer crashes in Linux.
But I also no longer need the LD_PRELOAD I mentioned in the original request.

I have a similar problem. Crash when launching Civ5 from Steam or when launching the game out of Steam directly with Ubuntu 18.04 with more than 8 virtual core (i have 12 virtual core).
Problem is completely solved by launching the game from bash command line :
taskset -c 0-7 steam steam://rungameid/8930