I tried to compile a project from my lab, the only things I changed from the original code using ccmake are:
CMAKE_CXX_COMPILER /usr/bin/clang++
CMAKE_CXX_FLAGS -fPIC -std=c++11
CMAKE_EXE_LINKER_FLAGS -stdlib=libc++
The project also depends from another lib that I compiled using the same options. The compiling works well but the linking fails at some points and give us
/usr/bin/ld: main.cpp.o: undefined reference to symbol '_ZNSsC1EOSs##GLIBCXX_3.4.14'
/usr/lib/x86_64-linux-gnu/libstdc++.so.6: error adding symbols: DSO missing from command line
The code is compiling on another machine but for some reasons, we do not manage to compile on this system. We tried a lot of things without success.
main.cpp.o: undefined reference to symbol '_ZNSsC1EOSs##GLIBCXX_3.4.14'
The -stdlib=libc++ should be used both at link and at compile time. I suspect that adding it to CMAKE_CXX_FLAGS will solve the problem.
Related
I am trying to compile QtWebApp with Qt5.5.1 onto the latest RPI4-Raspbian Buster and I am encountering inexplicable GLIBCXX unresolved symbols
What Works : QtWebApp cross compiled from windows to armhf using qt5.5.1 binaries natively compiled on Raspbian Buster works fine with the following components
Toolchain : raspberry-gcc8.3.0.exe installed on Windows 10.
Qt Binary Libs : Native compiled on RPI4 Raspbian Buster OS and
copied over to Windows 10.
Command line :
c:/SysGCC/raspberry/bin/arm-linux-gnueabihf-g++.exe -std=c++11 -fPIC -I.
{ALL QT INCLUDE DIRS}
-IC:/SysGCC/raspberry/arm-linux-gnueabihf/sysroot/opt/vc/include
-g -rdynamic -funwind-tables -Woverflow
{ALL QTWEB SOURCE FILES}
-LC:/SysGCC/pi4/pi4qt551/lib
-lQt5Core -lQt5Gui -lQt5Widgets
-lQt5Multimedia -lQt5MultimediaWidgets
-lQt5Network -lm -lpthread -o qtweb
This produces an arm executable that worksfine on RPI-4.
What fails
When compiling natively (which is what I want as the development env) on RPI4 the compilation strangely fails with the following error :
/usr/bin/ld: /tmp/ccnnsRCD.o: undefined reference to symbol '_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev##GLIBCXX_3.4.21'
What I have tried (didnt work)
1) Following suggestions from Converting std::__cxx11::string to std::string and passing -D_GLIBCXX_USE_CXX11_ABI=0 it fails with the following error :
/usr/bin/ld: /tmp/ccZfI5co.o: undefined reference to symbol '_ZNSaIcED1Ev##GLIBCXX_3.4'
where those symbol demangles to std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() and std::allocator<char>::~allocator() respectively.
2) I also ran all the combinations WITH/WITHOUT -std=c++11 and D_GLIBCXX_USE_CXX11_ABI=0 and these are the errors
WITH -std=c++11, WITHOUT -D_GLIBCXX_USE_CXX11_ABI=0
/usr/bin/ld: /tmp/ccnnsRCD.o: undefined reference to symbol '_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev##GLIBCXX_3.4.21'
WITH -std=c++11, WITH -D_GLIBCXX_USE_CXX11_ABI=0
/usr/bin/ld: /tmp/ccZfI5co.o: undefined reference to symbol '_ZNSaIcED1Ev##GLIBCXX_3.4'
WITHOUT -std=c++11, WITH -D_GLIBCXX_USE_CXX11_ABI=0
/usr/bin/ld: /tmp/cctFncwz.o: undefined reference to symbol '_ZNSaIcED1Ev##GLIBCXX_3.4'
WITHOUT -std=c++11, WITHOUT -D_GLIBCXX_USE_CXX11_ABI=0
/usr/bin/ld: /tmp/cchkJYdO.o: undefined reference to symbol '_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev##GLIBCXX_3.4.21'
3) I also copied the sysroot from the raspberry-gcc8.3.0.exe install on Win10 over to RPi-4 and passed that to gcc as its --sysroot location - which also fails with the ~basic_string() unresolver error. (I dont know how to verify if the --sysroot had any effect though I checked that gcc -v output doesnt have --with_libs in it as suggested in a GCC ignores --sysroot post)
INFO: The command line is exactly the same on the RPI4-Buster other than using gcc and not passing -IC:/SysGCC/raspberry/arm-linux-gnueabihf/sysroot/opt/vc/include
Question :
How is it that (assuming no glaring compile option mismatch ;) cross compiling with a gcc 8.3 toolchain from windows to arm-linux works but the same code base when compiled natively on raspbian buster with gcc 8.3 fails with what looks like GLIBCXX version mismatch in the Raspbian Buster OS binaries ?
I am stuck on this for 2 days now. Please suggest any other steps I can try here.
Are you executing the compiler as gcc instead of g++? That would cause this problem. Invoke g++.
Otherwise, Try adding -lstdc++ to your link flags.
Explanation:
The symbols are, obviously, from the C++ standard library. Under some circumstances - at the very least, when you invoke GCC using the gcc binary rather than g++ - GCC compiles C++ code, but doesn't automatically link against the GNU C++ standard library. If for some reason this isn't resolved by invoking g++, you could try adding the -lstdc++ flag, which means "link against the library libstdc++.so or libstdc++.a which you should find in the library search path".
I need to use OpenGL as a library in my project on my Ubuntu 15.04 64bit PC, which is built by CMake 3.0.2. I install packages: mesa-common-dev mesa-utils-extra libgl1-mesa-dev libglu1-mesa-dev libglapi-mesa libx11-dev libxi-dev libxinerama-dev libxcursor-dev libxrandr-dev
After run cmake and Makefile, I got these link error:
/usr/bin/ld: /home/user/CMU462/DrawSVG/asst1_drawsvg/lib/libglfw.a(x11_window.c.o): undefined reference to symbol 'XConvertSelection'
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libX11.so: error adding symbols: DSO missing from command line
I checked /usr/lib/x86_64-linux-gnu/libX11.so, it does exist.
I found a explanation, it seems I failed to link my project with X11 library. The answer says that add -lX11 option may fix this.
Alternatively I link
X11 library in CMakeLists.txt according to FindX11.cmake:
find_package(X11 REQUIRED)
message(STATUS "X11_FOUND = ${X11_FOUND}")
message(STATUS "X11_INCLUDE_DIR = ${X11_INCLUDE_DIR}")
message(STATUS "X11_LIBRARIES = ${X11_LIBRARIES}")
include_directories(${X11_INCLUDE_DIR})
link_directories(${X11_LIBRARIES})
target_link_libraries(MyProj ... ${X11_LIBRARIES})
Run cmake I got these output:
-- X11_FOUND = 1
-- X11_INCLUDE_DIR = /usr/include
-- X11_LIBRARIES = /usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so
But I still got the error aforementioned.
QUESTION: The X11 library can be linked by
using target_link_libraries in CMakeLists.txt, or
adding -lX11 option directly to compiling command
What's the difference between them? Does the link in CMakeLists.txt directly lead to a -lX11 option in Makefile generated?
If so, did I do something wrong in CMakeLists.txt?
UPDATE
Let's take this project as example, following is my build procedure.
Install required libraries: Install the OpenGL and other relative libraries (the GLEW and GLFW library is provided in this project): mesa-common-dev mesa-utils-extra libgl1-mesa-dev libglu1-mesa-dev libglapi-mesa libxi-dev libxinerama-dev libxcursor-dev libxrandr-dev
Run CMake: Then use the provided CMakeLists.txt, everything goes right.
Make: When make the project, this error occurred:
/usr/bin/ld: /home/user/CMU462/DrawSVG/asst1_drawsvg/lib/libglfw.a(x11_window.c.o): undefined reference to symbol 'XConvertSelection'
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libX11.so: error adding symbols: DSO missing from command line
I have searched for many times, all of the answers say that the incorrect link of glfw3 and x11 lead to the error:
missing the -X11 option. However in line 26 of CMakeLists.txt exists this option
the libraries show arranged in order. I check the dependencies with pkg-config --libs command, all libraries are arranged in order in line 17 to 29 of CMakeLists.txt.
The only potential reason for this is the order of the compile options of libraries (line 17 to 29) and the target_link_libraries (line 116) of CMakeLists.txt.
Otherwise, there must be another error omitted by me during my procedure.
I tried to follow the instructions on http://www.sigil.org/gwt-on-freebsd/ for building the plugin for the most recent version of Firefox. However linking fails with the error:
g++ -o build/FreeBSD_x86_64-gcc3-ff100/libgwt_dev_ff100.so build/FreeBSD_x86_64-gcc3-ff100/ExternalWrapper.o build/FreeBSD_x86_64-gcc3-ff100/ModuleOOPHM.o build/FreeBSD_x86_64-gcc3-ff100/FFSessionHandler.o build/FreeBSD_x86_64-gcc3-ff100/JavaObject.o build/FreeBSD_x86_64-gcc3-ff100/JSRunner.o build/FreeBSD_x86_64-gcc3-ff100/Preferences.o build/FreeBSD_x86_64-gcc3-ff100/XpcomDebug.o ../common/libcommon64.a -fPIC -shared -m64 -L../../../plugin-sdks/gecko-sdks/gecko-10.0.0/FreeBSD_x86_64-gcc3/lib -Wl,-rpath-link,../../../plugin-sdks/gecko-sdks/gecko-10.0.0/FreeBSD_x86_64-gcc3/lib -lxpcomglue_s -lxpcom -lnspr4 -lmozalloc -lxul
build/FreeBSD_x86_64-gcc3-ff100/ExternalWrapper.o: In function `GenericClassInfo':
/home/bofh/tmp/gwt_build/trunk/plugins/xpcom/../../../plugin-sdks/gecko-sdks/gecko-10.0.0/FreeBSD_x86_64-gcc3/include/nsIClassInfoImpl.h:132: undefined reference to `vtable for GenericClassInfo'
/usr/bin/ld: build/FreeBSD_x86_64-gcc3-ff100/ExternalWrapper.o: relocation R_X86_64_PC32 against `_ZTV16GenericClassInfo' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
gmake: *** [build/FreeBSD_x86_64-gcc3-ff100/libgwt_dev_ff100.so] Error 1
I'm not sure why it complains about missing -fPIC flag because it is present in command line for g++.
Please advice.
the problem was because of wrong SO library used - the one installed by libxul doesn't provide required function, so I copied libxul.so and libxulglue_s.so from firefox installation
and I was able to build the plugin successfully.
=====
after all, I was able to build latest GWT plugin for FreeBSD 9 / Firefox 10 / AMD64, see https://github.com/jdevelop/gwt-dev-firefox-freebsd
Why don't you install it via ports; /usr/ports/www/xpi-gwt-dev-plugin.
If you don't want to do that, at least try applying the patches that the port uses. The patches files/patch-config.mk and files/patch-xpcom-Makefile look relevant to this issue.
and sorry for my not really good english. I'll try my best :)
I am trying to compile a addin for my Casio graphic calculator in C. This works without problems when using the official SDK. Because it is only available for Windows, I want to use gcc.
So I got sh-rtems-gcc and it's binutils from macports and tried to compile my program according to this instructions. I copy-pasted the described addin.ld and crt0.s and placed my main.c and libfxsys.a (from the same guys as the instructions mentioned above) in the same directory. The sub-dir include contains fxsys' headers. I verified the presence of all the functions of the library in the .a file with nm.
When using this command for compilation:
sh-rtems-gcc-4.2.3 -m3 -mb -nostdlib -I./include -c crt0.s main.c
Everything works fine. But then im trying to link:
sh-rtems-gcc-4.2.3 -m3 -mb -nostdlib -L. -o myaddin.elf -Taddin.ld crt0.o main.o -lfxsys
and get the following error:
main.o: In function `__main':
main.c:(.text+0x248): undefined reference to `_Bdisp_AllClr_VRAM'
...
... (--- cut 16 other errors in the same format ---)
...
main.c:(.text+0x360): undefined reference to `_Sleep'
./libfxsys.a(locate.o): In function `_locate':
locate.c:(.text+0x28): undefined reference to `_locate_OS'
collect2: ld gab 1 als Ende-Status zurück
All the missing symbols are in the libfxsys.a. I have verified this with nm.
I have already played with the positions of the library in the command, as this is often mentioned as a source of failure in other posts found in google, but without success. I also tried adding and removing the -lgcc option that is used in the above mentioned instructions, without success.
My Host-Machine is a Intel Mac, OS X 10.6
Because I have no idea how to solve this problem, and get to compile my program, I have to ask: What am I doing wrong? How can I compile my program without using the SDK?
Thanks in advance,
xythobuz
Edit:
I have also tried linking with:
sh-rtems-ld -EB -L. -o myaddin.elf -Taddin.ld crt0.o --start-group main.o libfxsys.a --end-group
But it produces the same output as above.
I can't say the exact problem, but would investigate like this:
Find the library that contains the missing symbols. Use nm to see symbol names
Once you know which library contains the symbols make sure you're linking to it, and in the correct order. Try using recursive symbol resolution options -( -) with your linker.
I'm running Solaris, so it's possible that this is specific to running GCC on Solaris. If I use GCC to generate a shared object, and then run nm on it to see undefined symbols, there will always be a reference to main:
[624] | 0| 0|NOTY |GLOB |0 |UNDEF |main
If I manually generate the same shared object using ld, the reference to main doesn't exist. If I run nm on the system libraries in /usr/lib, none of them appear to have references to main. Only shared libraries I compile myself with GCC.
Apps compiled against these shared libraries work fine and without errors. But I still don't understand why the reference to main is there in the first place. Any clues?
You forgot the -shared option in your gcc link command line.
EDIT: and you forgot -fPIC option on your compile command line (which is causing all the relocation errors at link time).
If you still get relocation errors with -fPIC on all compile lines, then you should rebuild all the archive libraries which you link in (libtoast_datetime, libtoast_assert, etc.) with -fPIC as well.