my os default gcc version is 4.8.5, I compiled a program use gcc-11, so this program cannot be run for a older libstdc++.so.6, can I use libstdc++.so.6 from gcc-11 substitute older one gloabally(means as an default one at system wide)? after substitute, can other program compiled with gcc-4.8.5 also works well without any problem?
thanks very much
from https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html, we can see libstdc++.so.6.0.17 is forward compatible with libstdc++.so.6.0.18 - libstdc++.so.6.0.31 so far, but notice some compile flags for build gcc itself may cause forward incompatible if you build gcc youself.
We need to find a cross-compilation toolchain for an ARM embedded linux target that satisfies the following criteria:
Kernel 3.17
GLIBC 2.18
Recent version of GCC is required to compile some third-party code
Those requirements brought me to generate a custom cross-compilation toolchain using crosstool-ng. I selected the min kernel version, min glibc version and it seemed to work well until I tried to compile code containing C++.
Because the new GCC is using a more recent libstdc++ than what is available on the target, the executable won't run and we get an error like this:
/usr/lib/libstdc++.so.6: version `CXXABI_1.3.9' not found
The code compiled fine with an older version of GCC.
Looking at the configuration options for crosstool-ng I didn't find anything that would let me change the min libstdc++ version, like for glibc.
Is there a way to target an older libstdc++ version without downgrading GCC?
Can I use the headers and libstdc++.so files from the target to replace the ones GCC is using when cross-compiling?
I want to use latest gcc compiler, but target pc configuration only has libstdc++/libc suitable for gcc 4.8.
Is there any way to tell compiler to link against older abi?
I've managed to run my application, built with newer compiler (gcc 6), when I used -std=gnu++11 flag. It seems explicitly specifying standard version makes compiler link to maximum required version of abi.
According to the address-sanitizer home page it comes only with the gcc 4.8 or above. Isn't there anyway of using it with gcc 4.7?
No, there is no reliable way (to get ASAN before GCC 4.8). ASAN requires compiler support and is very intimately connected to your particular compiler (and version, and host and target systems, and specific configuration, etc...)
In other words, try to compile a recent GCC (that is, GCC 5.2 in july 2015; use that since ASAN did progress since 4.8 and you'll get more -fsanitize= options in recent versions of GCC) from its downloaded source code. See hints here & there. You should try some recent Linux distribution.
(on Linux or other POSIX systems, you don't need root privileges to configure, compile, and install gcc-mine-5 in $HOME/soft/; you need appropriate ../gcc-5.2/configure options, notably --prefix=$HOME/soft --program-suffix=-mine-5, then add $HOME/soft/bin/ in your PATH then run with CC=gcc-mine-5 e.g. for make)
I have inherited a piece of software which is having some issues. I believe the issues are related to the version of libc that is being statically linked.
I am building this on a Windows XP machine, targeting an x86 QNX Neutrino 6.3.2 machine.
Previously, the software built with GCC 2.95.3 (Well, technically, it's QNX's QCC that wraps and calls GCC)
Someone added a feature and had to port it to build with GCC 3.3.5 because the new feature needed it.
Now, the software is mine. I need to make some additions but have noticed weird behavior. After some digging, I found that there are static links to both libc for 2.95.3 and 3.3.5. According to QNX's web site, :
GCC 2.95.3 (from 6.2.1 or 6.3) and GCC 3.3.5 use different C++ ABIs
and have different name mangling. As a result, you can't link C++
binaries (objects, executables, libraries) built with GCC 2.95.3 with
binaries built with GCC 3.3.5.
This is a breaking ABI change, so I am obviously concerned. I wrote a small test for this
#include <stdio.h>
int main()
{
FILE *stream_ptr = popen("fakename","r"); /// use libc
return 0;
}
and built it with 3.3.5:
QCC -V3.3.5,gcc_ntox86 small.cpp -o small.out
then used strings to see what has been statically linked for this program
strings -a small.out | grep GCC
GCC: (GNU) 3.3.5 (qnx-nto)
GCC: (GNU) 3.3.5 (qnx-nto)
GCC: (GNU) 2.95.3
GCC: (GNU) 3.3.5 (qnx-nto)
As you can see, libc for GCC 2.95.3 has been statically linked.
My first question is: How can I make this link with a 3.3.5 version of libc?
My second question is: Why does it link with 2.95.3 in the first place?
What am I doing wrong/missing? Any suggestions are welcome.
(There's probably 60 other things in the project linking with 2.95.3 objects, and I need to fix them all, so implementing popen() and 59 of his closest friends myself isn't the best of ideas...)
Thanks,
Karl
UPDATE:
So I haven't figured out how to fix this yet, but a little bit of background for QNX 6.3.2 so folks who stumble upon this later don't have to figure this out the hard way:
You can use the verbose option for the linker ld --verbose and have it spit out everything it does. Note that I got the following output when I did that:
attempt to open C:/QNX632/host/win32/x86/usr/lib/gcc-lib/i386-pc-nto-qnx6.3.0/3.3.5//libc.a failed
attempt to open C:/QNX632/target/qnx6/x86/lib/gcc/3.3.5/libc.a failed
attempt to open C:/QNX632/target/qnx6/usr/i386-pc-nto-qnx6.3.0/lib//libc.a failed
attempt to open C:/QNX632/target/qnx6/usr/lib/libc.a failed
attempt to open C:/QNX632/target/qnx6/x86/lib//libc.a succeeded
As one can see, the linker is attempting to open the 3.3.5 version of libc.a, but it's simply not there. I took a look at 3 other coworkers computers, and the 3.3.5 version of libc.a is not there. How this is even working across a breaking ABI change, I'm not sure, but I am suspicious that some of the wonkiness in this project has to do with this discrepancy.
While this answers my original questions,
1) You can't make it link with nonexistant libc.a files,
2) It picks the 2.95.3 version because the 3.3.5 version isn't there,
it brings up new questions:
3) Why doesn't QNX ship a 3.3.5 version of libc.a with this version of Momentics? (or if they do, where do they hide it because I missed it.)
4) Are there any viable workarounds? I was able to build everything but the two most important servers in the project without using libc, but until I get the last two fixed up, I'm still searching for a solution.
Update to the Update:
Working with the QNX folks, they built me an unsupported, untested engineering version of libc.a, libm.a and libsocket.a with GCC 3.3.5, and everything has been good since.
When I compile for QNX 6.3.2, I always use 3.3.5 with the GNU C/C++ libraries. If you don't specify GNU, you will get Dinkum libraries by default. I have had problems in the past with Dinkum thread safety. Try these flags:
qcc -V3.3.5,gcc_ntox86 -Y_gpp
The -Y_gpp directs qcc to use the GNU libraries.
GCC 3.3 is prehistoric, isn't there a newer version for QNX?
There should be some option for the compiler or linker which will tell it to be verbose, which you could use to see all the library paths and libraries being linked to. That might show you how an older lib is being linked to.
In case someone else runs into a similar problem, to the best of my knowledge, here are the answers to the four questions I asked. They are not encouraging.
1) You can't make it link with nonexistent libc.a files. Of course.
2) It picks the 2.95.3 version of libc.a because the 3.3.5 version isn't there.
3) During discussions with the QNX folks, they stated that for QNX Neutrino 6.3.2, the official, tested compiler is only 2.95.3, even though GCC 3.3.5 is included in the shipped version of Momentics, it is not tested nor supported. It just happens to be there.
4) Options:
a) Go to a newer version of QNX which uses a newer version of GCC
b) Get source for libc (and libm as it turns out) and build it with GCC 3.3.5.
This one may pan out. Still waiting on QNX tech support.
c) Get already-built libraries from the QNX folks.
d) Don't use GCC 3.3.5 to build for Neutrino 6.3.2
Sincerely,
Karl