[Bug c++/91394] C++ ABI incompatibility (stdexcept)

tomas_paukrt at conel dot cz gcc-bugzilla@gcc.gnu.org
Thu Aug 8 04:27:00 GMT 2019


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.


More information about the Gcc-bugs mailing list