I'm trying to build a binary with GCC 4.9.0 that is backwards-compatible against libstdc++
. According to GCC's ABI Policy and Guidelines and Options Controlling C++ Dialect, the command line option -fabi-version
should do the trick; however, no matter which version I set, I still get imports of symbols from a version newer then desired, like this:
$ objdump -T binary | grep GLIBCXX_3.4.20
00000000 DF *UND* 00000000 GLIBCXX_3.4.20 _ZSt24__throw_out_of_range_fmtPKcz
I've tried -fabi-version=1
to -fabi-version=5
(ABI version 5 corresponds to GCC 4.6, which is guaranteed to be present on the target system), but those imports keep winding up in the resulting files.
How do I fix this? Going back to an old GCC version is not an option to me for other reasons.
the command line option
-fabi-version
should do the trick
No, that's completely unrelated to what you want. That option affects the code generated by the compiler, it does not mean you can link to an older version of libstdc++ (which is what you would need in order to stop depending on symbols in the newer libstdc++).
You cannot link to an older libstdc++ with a new GCC. The version of libstdc++ is tightly coupled to the version of GCC, so if you want to linker to an older libstdc++ then you need to compile with an older GCC.
You cannot tell libstdc++ to not use the new symbols, the reason it depends on them is because it needs them. Use an older libstdc++.
Going back to an old GCC version is not an option to me for other reasons.
Then you're screwed.
You either need to use an older GCC, or not link dynamically to libstdc++.so
.
On Red Hat Enterprise Linux or CentOS you would have the option of using a newer GCC from the Developer Toolset which avoids linking to the new libstdc++.so
but that is only compatible with the system GCC, which is GCC 4.4 for RHEL6 or GCC 4.7 for RHEL7. You can't use it to be compatible with GCC 4.6.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With