Hi, I have an oddly specific technical question, and I don’t know if anyone in the community would want to answer such a specific question without us having to buy a support contract for SLE, but I figure it wouldn’t hurt to try asking…
So, I’m in kind of a weird position with some C++ software I develop. For reasons I’d rather not go into, we can’t rely on distros to ship our software for us in their repos, or use flatpaks, so what we wind up doing is trying to create “universal” Linux binaries by compiling our software on CentOS 7 using devtoolset. The main reason why we chose CentOS 7 is because when we use a newer GCC, it doesn’t introduce dependencies on a newer libstdc++.
So for instance, on CentOS 7 the system compiler is GCC 4, but we were compiling the application with devtoolset’s GCC 7 for a long time. This meant we could take advantage of most GCC 7 features, but the application would run fine on systems that ship with an older libstdc++.
I started looking into how this works, and it appears that with CentOS 7, there’s some kind of “mixed-linkage” model, where symbols from the newer libstdc++ GCC 7 relies on are statically linked into the binary, but anything in the older version is dynamically linked to the standard system location, basically giving the best of both worlds in most cases and reducing binary size compared to simply statically linking an entire libstdc++ into the program.
So, now to my question… does OpenSUSE Leap allow something similar, using either that mechanism or a different one? Like for instance, can I use the g+±10 compiler to build an application, without introducing a dependency on a newer libstdc++ than what comes with GCC 7?
I appreciate that this is a very technical question and there might not be many people with answers on something like this.
Your question is rather vague. Is it possible to build gcc7 in the same way on openSUSE? Yes, of course, just do the same tricks as RHEL did. Has someone done it already? I do not know. Official gcc7 package does not do it. Will SUSE be interested in accepting patches to do it this way? I doubt it.
Briefly looking at devtoolset-7-gcc, changes to perform static linking against newer lbstdc++ appear to be pretty self contained, so it should be relatively straightforward to port them to SUSE gcc7 package if your business depends on it.
Hmm… I think I was trying to leave the question vague enough to allow for more possible solutions, but it seems like I will have to get a lot more concrete, perhaps using an example of this not working to explain what a working solution would look like. The first thing I should probably explain is that my goal here is to use the gcc-10 and g++10 packages on OpenSUSE Leap. That is, I want to achieve with GCC 10 something similar to what was done with GCC 7 previously.
On most distros that ship with a GCC 10 compiler as the system compiler, if I were to build an application with them, it would run fine on that specific distro. But if I were to try to run that binary compiled with GCC 10 on another distro that ships with, say, GCC 8 or 7, I would get a message that says something like:
/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.28’ not found
Which means, that compiler effectively creates binaries that are useless on distros that don’t ship a newer GCC and libstdc++. But if I use the devtoolset trick, with say, CentOS 8, then I can compile with GCC 10, and then the application will work and the message will not appear on the older distro.
From what testing I’ve done, it seems that OpenSUSE Leap does indeed do something similar… when I compile my application with the gcc-10 and g+±10 packages on here, I notice that it doesn’t introduce a dependency on GLIBCXX_3.4.28, and instead the highest version number I see when looking at the binaries in readelf is GLIBCXX_3.4.21. So it appears that it does indeed not require the person to have gcc-10 installed to run the binaries compiled with it.
I guess I just wanted to confirm that this is the case and it was intended to work this way, to make sure it wasn’t a fluke or something that it happened to work when I tried it.
> gcc --version
gcc (SUSE Linux) 7.5.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
Yes, I could install –
gcc8
gcc9
gcc10
gcc11
gcc12
gcc13
And as far as the “libstdc++” libraries are concerned (package libstdc++6-devel-gcc? «C++ 6»), they’ll be installed under the ‘/usr/include/c++/’ directory in sub-directories named 8, 9, 10, 11, 12, 13 …
Further the openSUSE/SUSE “update-alternatives” mechanism – the “update-alternatives” package – provides a mechanism to deal with various compiler versions installed in parallel on any given openSUSE/SUSE system.
Basically, by means of the directory ‘/etc/alternatives/’ symbolic links are maintained to choose a specific compiler version when and as needed …
Yes, but, in addition to the Standard C++ library, there are other compile-time specific libraries in the “libstdc++6-devel-gcc?” packages, which need to be addressed when compiling with a specific GCC version …
Thank you! It appears that the correct libstdc++6-devel-gcc10 package was pulled in when I installed the compiler. It looks like since you’re saying “compile-time specific libraries,” that means that I only need those libraries installed to compile the binaries, but not to run them?
So if someone else had a stock OpenSUSE Leap 15.5, they would be able to run my binaries compiled with GCC 10 on this OpenSUSE Leap 15.5 even though they personally don’t have it installed, right? So far, all signs are pointing to “yes.”
When you compile your program it will have dependency on whatever libstdc++ version it was linked against. The devtools trick makes it possible to install gcc itself without installing the corresponding shared run-time library by statically linking against it during build.
Assuming that, GCC 10 is using C++ 6 then, provided that, the standard C++ 6 library is installed on the target system then, everything should be OK on the target system.
But, a system regression test on the target system will be needed to confirm that, everything executes as expected / specified …
BTW, CMake allows the exact definition of which compiler and which libraries shall be used at compile time.
A negative side of ‘/etc/alternatives/’ is that, the definition there is for every user and project on the development system.