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.
