GCC 5.1 Officially Released

[carewolf]

I hope you're right because if not, this sounds like it can become a big mess for Valve and Steam and Linux gamers. Who knows which libraries these proprietary games use? Granted, some games may not of been developed with C++ at all but I imagine a good majority of native ports may. The way it sounds from that article, its a good idea to recompile your software even if it just links to a system library developed with C++ and built with the new ABI enabled.

Hence this part:

However, when another DSO such as libboost_filesystem.so is compiled with GCC 5 it will be compiled using either the old ABI or the new one, but not both, and programs linking to that DSO will usually need to use the same ABI to avoid linker errors. The C++ libraries that are part of Fedora 22 will be built using the old ABI, but they will be built using the new ABI in Fedora 23. Developers might need to recompile their programs using the new ABI in order to link to C++ libraries in Fedora 23.

In the case for Steam and the Steam Runtime, it includes it own libstdc++ and libgcc files but they often conflict when newer versions of those libraries are installed system-wide and require that they be removed (and in this case use the system installed GCC 5.1 versions) in order for Steam to function:

https://wiki.archlinux.org/index.php...runtime_issues

I have not seen any steam runtime libraries conflict with system libraries, and can't even imagine how that would happen. Steam games don't use many system libraries. Any library they need they usually ship with the game, so what the system has is usually not very relevant.

Boost libraries break ABI all the time, this is a smaller problem for boost than what they do all the time themselves.

Having read the changes again, I noticed the new libstdc++ is claimed to be double ABI. You can switch which one you rely on when you recompile by setting a define. I assume that means both will actually still work at link time.

A Dual ABI is provided by the library. A new ABI is enabled by default. The old ABI is still supported and can be used by defining the macro _GLIBCXX_USE_CXX11_ABI

[smitty3268]

I have not seen any steam runtime libraries conflict with system libraries, and can't even imagine how that would happen. Steam games don't use many system libraries. Any library they need they usually ship with the game, so what the system has is usually not very relevant.

Boost libraries break ABI all the time, this is a smaller problem for boost than what they do all the time themselves.

Having read the changes again, I noticed the new libstdc++ is claimed to be double ABI. You can switch which one you rely on when you recompile by setting a define. I assume that means both will actually still work at link time.

Some of the Mesa OpenGL drivers link into libstdc++, which is what causes the problems. The driver links to the distro standard (updated) version, while the game links to an older version included in the steam runtime. The driver ends up trying to call into the older version when it expects the newer one.

I actually think this might fix the issue. Since the ABI is being broken, i believe the driver will end up calling into it's own newer version of libstdc++ and it won't get merged back into calling the older one that the steam library contains.

I hope you're right because if not, this sounds like it can become a big mess for Valve and Steam and Linux gamers. Who knows which libraries these proprietary games use? Granted, some games may not of been developed with C++ at all but I imagine a good majority of native ports may. The way it sounds from that article, its a good idea to recompile your software even if it just links to a system library developed with C++ and built with the new ABI enabled.

Other than the GL drivers, nothing in a Steam game is supposed to call outside of Steam at all. They recommend using the steam runtime, and bundling anything else that's needed directly with the game, for precisely this kind of reason. So while it's possible things will break, if they are following the Valve recommendations then everything should be handled smoothly.

[carewolf]

Some of the Mesa OpenGL drivers link into libstdc++, which is what causes the problems. The driver links to the distro standard (updated) version, while the game links to an older version included in the steam runtime. The driver ends up trying to call into the older version when it expects the newer one.

Another way to solve that is to dlopen the OpenGL library with RTLD_DEEPBIND. That allowes the opened library to loads its own dependencies.

[cb88]

It's actually more consistent. If you want to avoid old-school non-numerical versioning labels like "alpha", "next", etc. during experimental stages would you use -1 instead? 4.9999?

Version numbers are for releases not development stop confusing yourself... its not like they have any relevance to the version control anyway if you want to specify a non release version you should specify the revision.

Also, it is definitely more brain damaged than Major.Minior.Revision of previous releases.

[konsolebox]

Version numbers are for releases not development

And where did we get that rule? The usual practice?

its not like they have any relevance to the version control anyway

Not if you don't mind sharing experimental stages to not-so-end users that would like to try newer versions ahead.

if you want to specify a non release version you should specify the revision.

Now that is pretty much a preference.

Also, it is definitely more brain damaged than Major.Minior.Revision of previous releases.

Care to elaborate? Because it's new?

[discordian]

And where did we get that rule? The usual practice?

Quite possibly, and its inconsequent if you think of the following bugfix releases, if they use the same scheme then 5.2.0 will be used until its done - at which point it becomes 5.3.0.

I already run into problems compiling 5.1.0 due to the libstdc++ breakage. I want the compiler to be largely independent of the OS libraries so I`d like to link everything (but libc,libm) statically. Unfortunately that results into trouble since the system libstdc++ doesnt contain the fancy new stuff (and it gets worse if you want a bootstrap compiler).
Breaking this cycle means I have to build a intermediate compiler with no dynamic libstdc++, and then build the real one.

[FireBurn]

Quite possibly, and its inconsequent if you think of the following bugfix releases, if they use the same scheme then 5.2.0 will be used until its done - at which point it becomes 5.3.0.

I already run into problems compiling 5.1.0 due to the libstdc++ breakage. I want the compiler to be largely independent of the OS libraries so I`d like to link everything (but libc,libm) statically. Unfortunately that results into trouble since the system libstdc++ doesnt contain the fancy new stuff (and it gets worse if you want a bootstrap compiler).
Breaking this cycle means I have to build a intermediate compiler with no dynamic libstdc++, and then build the real one.

I think 5.2 is the next bug fix release from the 5 branch - next years big release (current development) is 6.0. When that is actually released it'll be 6.1

[discordian]

I think 5.2 is the next bug fix release from the 5 branch - next years big release (current development) is 6.0. When that is actually released it'll be 6.1

Well, thats kinda my point (but Im not sure if thats the scheme either)

Development of 5.1.0 happens in 5.0.0 (pure development branch).
Development of 5.2.0 happens in 5.1.x (branch of a release) or 5.2.0 (development branch that later turns into release)?

This seems inconsequential to me, as I said.

[PuckPoltergeist]

Well, thats kinda my point (but Im not sure if thats the scheme either)

Development of 5.1.0 happens in 5.0.0 (pure development branch).
Development of 5.2.0 happens in 5.1.x (branch of a release) or 5.2.0 (development branch that later turns into release)?

This seems inconsequential to me, as I said.

5.2, 5.3 etc will be only bugfix releases, like 4.9.2 was. Next feature release will be gcc-6, that is developed in 6.0-branch.

[jgpallero]

OpenMP ans OpenACC

Well, GCC 5.1 comes with OpenMP 4.0 and a first attempt to OpenACC 2.0a. These can produce code to be executed on accelerators, such as GPUs but, are the code executed in the accelerator or in the CPU? What is needed in order to compile code for a NVIDIA card with GCC 5.1 and OpenMP or OpenACC? Only the official propietary NVIDIA drivers?