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

2019-08-07 Thread redi at gcc dot gnu.org
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.

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

2019-08-07 Thread tomas_paukrt at conel dot cz
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)

2019-08-08 Thread pinskia at gcc dot gnu.org
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)

2019-08-08 Thread redi at gcc dot gnu.org
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.