[Bug c++/91394] C++ ABI incompatibility (stdexcept)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91394 --- Comment #4 from Jonathan Wakely --- Some programs which happen to not use any new features might work with an older version of libstdc++.so but that is not guaranteed, and definitely not supported. Removing one or two functions from a header is not going to solve the problem in the general case. Using _GLIBCXX_USE_CXX11_ABI is also not a solution for this, that's not what it's for. If you want to run with the libstdc++.so from GCC 4.9.4 then compile with GCC 4.9.4, that's guaranteed to work.
[Bug c++/91394] C++ ABI incompatibility (stdexcept)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91394 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andrew Pinski --- Forwards compatible is not guaranteed; only backwards compatible. That is you can compile with X and run with (X+1) libraries but not the opposite way around. This is true with almost all software including but not limited to GLIBC, GCC, libstdc++ (and even Windows).
[Bug c++/91394] C++ ABI incompatibility (stdexcept)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91394 tomas_paukrt at conel dot cz changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #2 from tomas_paukrt at conel dot cz --- > What has the glibc version got to do with anything? We have upgraded glibc 2.25 to glibc 2.30 and it introduced similar compatibility issue, because new symbols (e.g. fcntl64@GLIBC_2.28) were present in a fresh cross-compiled program, so the binary cannot run on the old system, but in this case there is a simple workaround (.symver fcntl64,fcntl@GLIBC_2.4) that makes the program work again, so I was looking for a similar workaround for libstdc++.so and I have found _GLIBCXX_USE_CXX11_ABI. > If it's not present on the old system that means you're not using the > libstdc++.so from GCC 7.4.0, which you're required to do. You can't compile > with a new GCC and then use an old libstdc++.so at runtime. That's always > been true. Defining _GLIBCXX_USE_CXX11_ABI has nothing to do with that. Sorry, but this is not true. If some program is cross-compiled with GCC 7.4.0 using -std=gnu++98 and _GLIBCXX_USE_CXX11_ABI is set to zero then the binary can be run on the old system with the old libstdc++.so from GCC 4.9.4, because it does not use any new symbol. Maybe it is a side effect, but it does not change the fact that it simply works. Unfortunately _GLIBCXX_USE_CXX11_ABI does not help in case of using -std=gnu++11, because conditional compilation in some header files ignores _GLIBCXX_USE_CXX11_ABI and rely only on __cplusplus >= 201103. I have cross-compiled two programs with patched "stdexcept" and they now run on the old system too, so I believe that there is a way how to make all binaries portable.
[Bug c++/91394] C++ ABI incompatibility (stdexcept)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91394 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- (In reply to tomas_paukrt from comment #0) > Some C++ programs cross-compiled with GCC 7.4.0 using -std=gnu++11 do not > work on a system which have glibc 2.25 cross-compiled with GCC 4.9.4 even if > the symbol _GLIBCXX_USE_CXX11_ABI was set to zero during cross-compilation. What has the glibc version got to do with anything? > A program that calls constructor out_of_range(const char*) will be using > symbol _ZNSt12out_of_rangeC1EPKc@GLIBCXX_3.4.21 which is not present on the > old system If it's not present on the old system that means you're not using the libstdc++.so from GCC 7.4.0, which you're required to do. You can't compile with a new GCC and then use an old libstdc++.so at runtime. That's always been true. Defining _GLIBCXX_USE_CXX11_ABI has nothing to do with that.