Works mostly fine here on my AMD Rx480 on Mesa-17.30.0-devel (Padoka PPA), the only thing that does not work is the cutscenes, there are sound but no video for some reason. Only 6 hours in at the moment and have not made it further than Sector 3 but oboy is this one fun piece of a game!

View this comment - View article - View full comments

Quoting: Guest

Quoting: F.UltraIf it's glibc (and not libc++) can you not do like: https://web.archive.org/web/20160107032111/http://www.trevorpounds.com/blog/?p=103 [External Link] ? Should be no reason to build a GCC toolchain, just download the appropriate libc package for your distribution that contains the older version and use the info from the link.

That method is completely impractical - you would end up having hundreds of symver statements, and then it is no guarantee things would work properly. Similarly you would have to cook up the symvers for any library you wanted to build.

So then we are back to how we have always done things like this, keep a chroot around with those old versions of libs and compilers and build your stuff there. Now a days people perhaps use various containers for this instead, but I'm not there yet :)

View this comment - View article - View full comments

Quoting: GuestBy far one of the biggest issues with libs on Linux is glibc versioning. While they are not supposed to break the ABI, they frequently do. Making sure your game is compiled to use a sufficiently older version is a nightmare as well - you basically have to build your own GCC toolchain. I have found no other way of doing it.

IMO an rpath in the executable is a far better solution than manually dicking about with LD_LIBRARY_PATH. This way you would only have to have an rpath like "./libs.x86_64/" in your 64 bit executable, and "./libs.i386/" in your 32-bit one. A launch script using "arch" to identify whether the 32 or 64 bit executable should be launched takes care of the rest.

It is true that the Steam Runtime could use updating, however this would introduce problems as well for the same reason as using the system libraries introduces problems.

If it's glibc (and not libc++) can you not do like: https://web.archive.org/web/20160107032111/http://www.trevorpounds.com/blog/?p=103 [External Link] ? Should be no reason to build a GCC toolchain, just download the appropriate libc package for your distribution that contains the older version and use the info from the link.

View this comment - View article - View full comments

Quoting: Guest

Quoting: F.Ultra#1 have existed on Linux since day one. This is where the semantic versioning of the shared library kicks in, unfortunately not everyone who writes shared libraries follows the rules for semantic versioning and simply put their actual version there.

No it hasn't, not as I describe. Semantic versioning is basically naming symbols in a particular way, but then the programmer has to go to a lot of effort to explicitly bind to those symbols rather than the library's default ones.

Also .so has no version number embedded in it - this is only actually ever indicate by the file name, which is arbitrary and can be modified too easily to falsify or remove this information. It would be better if it was explicitly stated inside the ELF file.

Are you talking about linking with an older version of a lib than what you have installed? Because by default the linker (when compiling) will bind to the SONAME version of the library that you have installed.

The SONAME is also not only in the filename but also stored inside the ELF file:
f.ultra@ubuntu:~$ objdump -p /usr/lib/x86_64-linux-gnu/libmysqlclient.so | grep SONAME
  SONAME               libmysqlclient.so.18

When you try to run an application linked with this on a machine which only have .so.17 or .so.19 then ldd will fail since your application needs the v18 ABI interface of this library. I don't really understand what it is that your extended version from Mach-O is supposed to do more than this anyway, it cannot make your application use v17 or v19 since it cannot know what it is that have changed in between those versions.

So I might misunderstand what you are saying, so please enlighten me!

View this comment - View article - View full comments

Quoting: GuestThe problem with the "just ship all your dependencies" argument is how far do you take it ? A simple example, we need to ship libcurl. If we want https support, that typically depends on OpenSSL. Do we now have to ship OpenSSL ? What about the things OpenSSL depends on ?

Say we have a GTK3 UI somewhere. Do we ship the whole of GTK3 and all its dependencies ? That's pretty large. You're probably thinking "but everyone will have GTK3" - not so. Some people use setups which are exclusively Qt, or GTK2.

"Just statically link" is also a bad idea - that doesnt solve anything, and in fact it makes future compatibility WORSE because now you cannot replace the older versions of libraries at all. If there's a security issue in the old build, you're stuck with it. Not to mention if you are a complex game (like ARMA 3) then statically linking libs is a huge waste of VM space.

IMO, the Linux runtime linker (ld.so) needs support for two things:

1) Library versioning *at the load stage*, with embedded version numbers in the library files themselves. The method Mach-O uses of dual version numbers - library version and ABI compatibility version, should be adopted. It's easy to add to ELF.

2) Weak linking. This means that you can specify you want to link to a library IF it exists, but still run if it doesn't - you can check at run time if the library loaded or not. Currently this has to be implemented manually with dlopen/dlsym, and it's a lot of hassle.

#1 have existed on Linux since day one. This is where the semantic versioning of the shared library kicks in, unfortunately not everyone who writes shared libraries follows the rules for semantic versioning and simply put their actual version there.

View this comment - View article - View full comments

Quoting: silmeth

Quoting: F.UltraIf only writers of shared libraries would think more about backwards compatibility...

It would suffice if they followed semantic versioning with regard to their libraries’ APIs – one would know which shared versions are compatible. Some libs would have a few hundred new major versions every year – but at least it’d be obvious that every game needs its own separate copy of it in its own version.

At least until we dive into compiled C++ libraries where the version of the compiler that compiled the library and a game binary matters, as C++ has no stable ABI (so library compiled with newer gcc might, and probably will, stop working with old executable).

Following the semantic versioning would most definitely help yes, but I see many libraries that make completely unneeded changes to both API and ABI.

Once in a while I think that whenever a library writer creates a version that is no longer ABI compatible then they should be required to write a shim library for the previous version that uses the new version, that way security fixes and so on would still be applied to the users of the old version and distributions could install all the hundreds of shims when you install a library (since all the old versions are just small shims they should be very small in size so the overhead should not be that great) or perhaps as a libxxx-shim package just like we have -dev/-devel packages on most distributions.

View this comment - View article - View full comments

Quoting: kf

- Unless running via a .sh (LD_LIBRARY_PATH=./lib:$LD_LIBRARY_PATH DISPLAY=:0 stdbuf -i0 -o0 -e0 ./MainBinary), native extensions (.so) cease to load correctly.

Isn't this standard when you ship games that require specific versions of libraries? I've even seen many steam games do this even with the steam runtime avaliable.

Yes, it's basically the equivalent of how they on Windows have to bundle all their external dependencies and install them in the same folder as the game (and thus users have millions of the same DLL:s on their hard drives).

If only writers of shared libraries would think more about backwards compatibility...

View this comment - View article - View full comments

Quoting: chancho_zombieafter trying with a second visa debit card, over steam, it finally worked!! you are right @Comandante Ñoñardo, debit cards work!! but not all of them.

Are you sure that it's not some geographical security setting on your VISA? On my bank I can select and deselect various geographical regions where my VISA can be used, the default is enabled for my local country only.

View this comment - View article - View full comments

Quoting: MayeulC

Quoting: F.Ultra

Quoting: MayeulCI remember a game that lasted me six months, singleplayer on civ V (biggest map, slow time). But not every game is like this.

Usually, playing with your friends as an ally is less boring, as they can see your troops.

This is also a good candidate as a "mail-chess"-like (see freeciv 2's website).

A bit sad to hear this. Would love to hear the complete technical analysis of what happens here. The function names, actual differences, etc.

Is it floating point related, RNG related, other? Wine doesn't seem to have a problem with this. Wouldn't using some parts of winelib help? (It is LGPL, so definitely linkable against).

Wine does not experience this problem, but it will also not fix it. Because the difference in the floating points are due to the compiler (yes different math libraries can also cause this but there is a basic difference on the compiler level) so one fix would of course be to force all windows devs to compile with gcc, but for some strange reason most windows devs prefer the Visual Studio compiler.

Ooh,that's right :)

Another solution could then be writing a hybrid: separate the game logic/simulation into its own library (or object file), and link it later (might need a DLL loader, but I don't think it's that complicated; and maybe a shim or two if the calling conventions are different).

In any case, I trust Feral to be competent enough to know the right thing to do (and choose whether to spend time on doing it).

Or rather the companies doing these multiplayer protocols should stop using the raw float values since they cannot be trusted (different raw values of a float can produce the same decimal representation which is the problem) and there is nothing that says that a new version of the Visual Studio compiler will produce raw float values that is binary compatible with the current/old ones. Would probably speed up things as well if they changed to something sane like i.e scaled integers.

View this comment - View article - View full comments

Quoting: MayeulCI remember a game that lasted me six months, singleplayer on civ V (biggest map, slow time). But not every game is like this.

Usually, playing with your friends as an ally is less boring, as they can see your troops.

This is also a good candidate as a "mail-chess"-like (see freeciv 2's website).

A bit sad to hear this. Would love to hear the complete technical analysis of what happens here. The function names, actual differences, etc.

Is it floating point related, RNG related, other? Wine doesn't seem to have a problem with this. Wouldn't using some parts of winelib help? (It is LGPL, so definitely linkable against).

Wine does not experience this problem, but it will also not fix it. Because the difference in the floating points are due to the compiler (yes different math libraries can also cause this but there is a basic difference on the compiler level) so one fix would of course be to force all windows devs to compile with gcc, but for some strange reason most windows devs prefer the Visual Studio compiler.

View this comment - View article - View full comments