Is it possible that there are 2 versions of libstdc++.so.6 installed, and while compiling it is using a different version
In my code I am reading a binary file and storing the data in mysql server.
While compiling the file. The file compiles properly.
Command used for compiling
g++ -std=c++11 -Wall -I/usr/include -o mkt MtkF.cpp -L/usr/lib -lmysqlcppconn
While running the file I get and error as -
libstdc++.so.6: version `GLIBCXX_3.4.20' required by /lib/libmysqlcppconn.so.7
libstdc++.so.6: version `GLIBCXX_3.4.21' required by /lib/libmysqlcppconn.so.7
OS CentOS
On running this command -
strings /usr/lib64/libstdc++.so.6 | grep LIBCXX
It return values till GLIBC19
Have looked at other solutions also, but no luck.
Related
I am trying to install Armadillo with Homebrew with
brew install armadillo
but when I try to compile with
g++ example.cpp -o example -std=c++11 -O2 -larmadillo
it gives the following error:
fatal error: 'armadillo' file not found
How can I solve this problem?
I'm guessing here that you have a new M1 Mac. The issue in this case is that ARM-native homebrew is installed to /opt/homebrew/ by default, meaning armadillo was installed to /opt/homebrew/include/ which is not in your search path.
To see if this is the case, try providing the paths as follows:
CPATH=/opt/homebrew/include LIBRARY_PATH=/opt/homebrew/lib g++ example.cpp -o example -std=c++11 -O2 -larmadillo
To avoid the issue in general, I'm running with those CPATH and LIBRARY_PATH variables exported in my ~/.zprofile file (using zsh). I found this answer on the apple stack exchange helpful.
I encountered an odd difference between the binary produced by a 4.9.2 G++ and a 8.2.0 G++ on a Linux, when upgrading from the former to the latter. I was able to narrow it down to the below minimized snippet
//main.cpp
int main(){}
//emptylib.cpp
#!/bin/sh
#to build and verify output
rm -rf bin lib *.o
gcc_bin=/path/to/gcc_4.9.2/bin
#gcc_bin=/path/to/gcc_8.2.0/bin
${gcc_bin}/g++ -B${gcc_bin} -c main.cpp
${gcc_bin}/g++ -B${gcc_bin} -c emptylib.cpp
${gcc_bin}/g++ -B${gcc_bin} -shared emptylib.o -o libemptylib.so
${gcc_bin}/g++ -B${gcc_bin} main.o -o main -L. -lemptylib
mkdir bin
mkdir lib
mv libemptylib.so lib/
mv main bin/
ldd bin/main
The result is a bit strange, because I have provided no -rpath=../lib, but all the same, with the 4.9.2 compiler driver I end up with (in the output of ldd):
libemptylib.so => /path/to/bin/../lib/libemptylib.so
and with 8.2.0
libemptylib.so => not found
the lib does not resolve, as I would expect. I haven't been able to see any documentation that hints at a search for ../lib in any version, but I would not expect this to be a behavior by any version. Was this a bug in 4.9.2 or some earlier version or something that shouldn't have happened in the first place?
As a side note, the 8.2.0 and the 4.9.2 don't have an ld inside of their bin directory (despite me putting the -B in the code snippet), so both compiler drivers are using the /usr/bin/ld (I've verified as much) and producing different results based on the compiler driver alone.
Update:
On request, I ran readelf -d bin/main on both binaries and I did receive different output for rpath. GCC 4.9.2 gave me:
0x000000000000000f (RPATH) Library rpath: [$ORIGIN:$ORIGIN/../lib64:$ORIGIN/../lib:/path/to/gcc_libs/lib64:/path/to/gcc_libs/lib:/path/to/gcc_4.9.2/lib64:/path/to/gcc_4.9.2/lib]
where 8.2.0 did not have that
0x0000000000000001 (NEEDED) Shared Library: [libemptylib.so]
So I guess I have an answer to what happened. So how did this end up in my binary in 4.9.2, and why did it change between the two versions where now it doesn't in 8.2.0?
I did receive different output for rpath.
rpath: [$ORIGIN:$ORIGIN/../lib64:$ORIGIN/../lib:/path/to/gcc_libs/lib64:/path/to/gcc_libs/lib:/path/to/gcc_4.9.2/lib64:/path/to/gcc_4.9.2/lib]
So the difference is in how GCC 4.9.2 vs. 8.2.0 were configured.
I am guessing that 8.2 came from your distribution (or at least was configured with default installation paths), whereas 4.9 was configured to be installed into /path/to/gcc_4.9.2.
That explains why 4.9 adds -rpath with /path/to/gcc_4.9.2/lib64 for a 64-bit builds. It does not however explain where $ORIGIN of /path/to/gcc_4.9.2/lib (the latter shouldn't be part of a 64-bit build) come from.
Configuring GCC so that it puts exactly what's necessary, no more and no less, is a bit of a black magic. I wouldn't be surprised if 4.9 had some bugs in that area.
i guess the problem is that the g++ version 7.3.0 still using the old stdc lib , im not sure ..
how can i check ? and how can i upgrade to new versions as the runtime error im getting of the app
looks like this :
./a.out
./a.out: /lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by ./a.out)
./a.out: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by ./a.out)
This is what i have now :
g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --disable-multilib --enable-languages=c,c++
Thread model: posix
gcc version 7.3.0 (GCC)
this is my compile/link flags :
g++ echo.cpp src/*.cpp -Wall -O0 -g -std=c++14 -I/home/vagrant/libuv/include -Isrc -L/home/vagrant/libuv/build -lssl -lcrypto -Wl,--no-as-needed -Bstatic -luv_a -ldl -lpthread
and those are my stdc files after searching :
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/32/libstdc++.so
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/libstdc++.so
/usr/local/lib64/libstdc++.so
/home/vagrant/gcc-7.3.0/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so
/home/vagrant/gcc-7.3.0/stage1-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so
/home/vagrant/gcc-7.3.0/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so
You dynamically linked the C++ standard library, then replaced it with a different version.
The version now installed on your computer is not compatible with the one your program requires, so it cannot run.
Rebuild your project, so that it links against the newer version, or downgrade GCC.
In future you may wish to consider statically linking the standard library instead, so that this particular version is just bundled with your executable. But this has downsides (which you can research).
I have a Linux-based application, running under Ubuntu 12.04 LTS, that compiled, linked, and ran with no problem.
I recently upgraded my Ubuntu to 14.04 LTS and encountered problems compiling and linking the app.
The compilation problems were solved by manually modifying my local copy of Boost 1.48 in two files (include/boost/config/stdlib/libstdcpp3.hpp and include/boost/thread/xtime.hpp). At this point the app compiled successfully.
The problem I have is that the linkage fails with the error message:
c++: error: unrecognized command line option ‘-Wl’
I use CMake to enable compiling the app on multiple platforms. Here is the linker script generated by CMake. Note that the "-Wl" options are now inexplicably unrecognized by /usr/bin/c++:
/usr/bin/c++
-fno-stack-protector
-g
-Wl
CMakeFiles/Project.dir/main.cpp.o
CMakeFiles/Project.dir/TestCallback.cpp.o
CMakeFiles/Project.dir/utils.cpp.o
CMakeFiles/Project.dir/Request1.cpp.o
CMakeFiles/Project.dir/Response1.cpp.o
CMakeFiles/Project.dir/TextChatRequest.cpp.o
CMakeFiles/Project.dir/TextChatResponse.cpp.o
-o
/home/user/private/Project/Project_Release_1_2_Codename/Build/bin/Debug/Project
-L/home/user/Libraries/Ubuntu32_12.04/boost_1.48/lib
-L/home/user/Libraries/Ubuntu32_12.04/SqlLite_3.6/lib
-L/home/user/Libraries/Ubuntu32_12.04/taglib_1.7/lib
-L/home/user/Libraries/Ubuntu32_12.04/JSON_1.0/lib/Debug
-L/home/user/private/Project/Project_Release_1_2_Codename/Build/../lib/libUbuntu32/Debug
-rdynamic
/home/user/private/Project/Project_Release_1_2_Codename/lib/libUbuntu32/Debug/libAPI.a
/home/user/private/Project/Project_Release_1_2_Codename/lib/libUbuntu32/Debug/libInternals.a
-lboost_thread
-lboost_system
-lboost_filesystem
-lboost_program_options
-ltaglib
-lJSON
-lpthread
-Wl,-Bstatic
-lsqlite3
-Wl,-Bdynamic
-ldl
-Wl,-rpath,/home/user/Libraries/Ubuntu32_12.04/boost_1.48/lib:/home/user/Libraries/Ubuntu32_12.04/SqlLite_3.6/lib:/home/user/Libraries/Ubuntu32_12.04/taglib_1.7/lib:/home/user/Libraries/Ubuntu32_12.04/JSON_1.0/lib/Debug:/home/user/private/Project/Project_Release_1_2_Codename/Build/../lib/libUbuntu32/Debug
Here is version information for the software I'm using:
Ubuntu:
14.04.1 LTS (trusty)
c++ compiler/linker:
(Ubuntu 4.8.2-19ubuntu1) 4.8.2
CMake:
Version 2.8.12.2
Why doesn't the linker recognize "-Wl" commands? Did my upgrade to 14.04 LTS modify the linker software libraries? How can I get my app back up and linking?
On line 4 of the command you have -Wl without any actual linker options.
https://gcc.gnu.org/gcc-4.7/porting_to.html
Right at the top of this page is the following:
Earlier releases did not warn or error about completely invalid
options on gcc/g++/gfortran etc. command lines, if nothing was
compiled, but only linking was performed. This is no longer the case.
For example,
gcc -Wl -o foo foo.o -mflat_namespace
Now produces the following error
error: unrecognized command line option ‘-Wl’
error: unrecognized command line option ‘-mflat_namespace’
Invalid options need to be removed from the command line or replaced by something that is valid.
12.04 LTS packaged GCC 4.6, you've now jumped to 4.8 and -Wl on its own is no longer a valid option (or rather it never was, GCC is just more pedantic now).
As mentioned by others previously, it indeed turned out that my CMake script was injecting a lone, solitary, seemingly unnecessary "-Wl" via the CMAKE_EXE_LINKER_FLAGS setting:
if(LINUX)
set(THIRDPARTY_LIBS boost_thread boost_system boost_filesystem boost_program_options taglib JSON)
set(OS_LIBS pthread sqlite3.a dl)
set(CMAKE_EXE_LINKER_FLAGS "-Wl")
set(PREPROCESSOR_DEFINITIONS ${PREPROCESSOR_DEFINITIONS};/DTAGLIB_STATIC)
endif(LINUX)
When I removed this setting, the build succeeded. This oversight has been around a while, with the earlier version of gcc not minding. The latest gcc, however, is more pedantic and flagged it as an error.
I need to use C++ 11, so I updated my GCC from 4.1 to 4.7. I compile the source code and make install it. gcc -version will show 4.7.0 (everything looks good). I compiled my program using:
g++ -O2 -std=c++11 -o wdSer wdSer.cpp
After that I run my program ./wdSer, there are some information as follows:
./wdSer: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by ./wdSer)
./wdSer: /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.5' not found (required by ./wdSer)
./wdSer: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.10' not found (required by ./wdSer)
./wdSer: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by ./wdSer)
Who can tell me how to solve it?
First try this:
LD_LIBRARY_PATH=/usr/local/lib64:$LD_LIBRARY_PATH ./wdSer
/usr/local/lib64 is the default library directory for a 64bit build of gcc .
Setting LD_LIBRARY_PATH to contain that directory tells the linker to look in that directory for library files.
If that does not work, look at the output of g++ -v
On my system, I get this:
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.8.2/libexec/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.8.2/configure --prefix=/usr/local/gcc-4.8.2 --with-isl=/usr/local/isl-0.12.2 --with-cloog=/usr/local/cloog-0.18.1
Thread model: posix
gcc version 4.8.2 (GCC)
In this output, you are looking for a directory following --prefix. Add /lib64 to the end of that prefix, and you'll have your library directory.
On my system, it's /usr/local/gcc-4.8.2 , so I need the linker to look in /usr/local/gcc-4.8.2/lib64 to find my libstdc++ .
So I run programs like this:
LD_LIBRARY_PATH=/usr/local/gcc-4.8.2/lib64:$LD_LIBRARY_PATH ./a.out
If you don't want to set your LD_LIBRARY_PATH before running your programs, you should build them with -Wl,-rpath= , like this:
$ g++ -std=c++11 -o wdSer -Wl,-rpath=/usr/local/lib64/ wdSer.cc
You can use ldd on a program to see where the shared libraries it is linked to are found:
$ ldd a.out
linux-vdso.so.1 => (0x00007fff8a506000)
libstdc++.so.6 => /usr/local/gcc-4.8.2/lib64/libstdc++.so.6 (0x00007fa3c6aaf000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fa3c6811000)
libgcc_s.so.1 => /usr/local/gcc-4.8.2/lib64/libgcc_s.so.1 (0x00007fa3c67fa000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa3c646f000)
/lib64/ld-linux-x86-64.so.2 (0x00007fa3c6bbc000)
Here, a.out is a program I built with the option -Wl,-rpath=/usr/local/gcc-4.8.2/lib64 , so the linker looks there first, and finds the libstdc++ that goes with my gcc 4.8.2 install.
Please see the documention for the -v flag: http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Overall-Options.html#Overall-Options (and search for -v )
the -Wl flag : http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Link-Options.html#Link-Options (and scroll down to the bottom)
and the -rpath flag: https://sourceware.org/binutils/docs-2.24/ld/Options.html#Options (and search for -rpath)