I have been working on a pet project for a while, and I recently encountered a runtime symbol lookup error. As the error itself does not provide much information I have no idea how to solve it.
I am using Eclipse Mars.
I include the following headers:
#include <GL/glew.h> //glew-1.12.0
#include <GLFW/glfw3.h> //glfw-3.1.1
#include <iostream>
#include <fstream>
#include <algorithm>
#include <math.h>
My console output looks normal when I build the project.
12:05:00 **** Incremental Build of configuration Debug for project Game ****
make all
Building file: ../main.cpp
Invoking: Cross G++ Compiler
g++ -I/usr/include/libdrm -I/usr/local/include -O0 -g3 -Wall -c - fmessage-length=0 -MMD -MP -MF"main.d" -MT"main.d" -o "main.o" "../main.cpp"
Finished building: ../main.cpp
Building target: Game
Invoking: Cross G++ Linker
g++ -L/usr/local/lib -o "Game" ./main.o -lGL -lGLEW -lGLU -lglfw3 -lX11 -lXcursor -lXi -lXinerama -lXrandr -lXxf86vm -lpthread
Finished building target: Game
12:05:01 Build Finished (took 567ms)
But when I try to run it I get the following error:
/home/lokko/git/buum/Game/Debug/Game: symbol lookup error:/home/lokko/git/buum/Game/Debug/Game: undefined symbol: __glewClipControl
I am a hobbyist programmer and everithing I know I have learned myself so it would be nice if the anwser was as clear as possible about what I need to do to get this to work. The specific function causing the problem is
glClipControl(GLenum origin,GLenum depth);
Edit:
I am running opengl 4.5 on Nvidia 840m and using proprietary Nvidia drivers. (349)
Solution:
So everything started to work after I the last Ubuntu update. Dont know what it was. The last update before that was less than 24 hours ago. I wouldnt consider this an actual solution and I will post when this issue returns.
The problem you're running into is, that OpenGL has to classes of symbols: OS ABI defined symbols, which are symbols and functionality which is asserted to be available for any OpenGL implementation running on the system (for Windows this is OpenGL-1.1, for Linux LSB4 OpenGL-1.2 and with the recently released LSB5 it's OpenGL-2.1).
Anything that's outside of those asserted to be available ABIs may be not available and must be first tested for presence, then loaded at runtime through the OpenGL extension mechanism. This covers core OpenGL versions higher than what's specified in the ABI, but also vendor specific extensions. In your case glClipControl is a function that got introduced with OpenGL-4.5 (which at the time of writing this is the highest OpenGL version around).
So for this function to be available you need a fairly recent GPU (well, everthing built by AMD and NVidia after 2012 should do the trick) and you need the latest drivers for that GPU.
That error is telling you, that the function you'd like to use is not supported by either your GPU or the OpenGL implementation you have.
Now in case of a run-of-the-mill Linux you're likely using the Mesa drivers (which go only up to OpenGL-3.x so far; OpenGL-4.x support will be there eventually) or a rather outdated vendor proprietary driver that's not OpenGL-4.5 capable.
Solution:
Check that your GPU is not made by Intel (there are only Mesa drivers for Intel GPUs)
Check that your GPU actually supports OpenGL-4.5
Download the latest proprietary drivers for that GPU and install those
Related
I am using Qt 5.6 with Qt Creator 4.3 on macOS Sierra 10.12.
I am building a Qt based application that uses OpenGL and OpenCL.
Software or system updates somewhere appear to have broken Qt Creators' ability to find the headers for OpenGL and OpenCL headers.
I have tried reinstalling Qt, Reinstalling Xcode and the Mac SDK and none of these options make it work.
The weird thing is my app compiles. QtCreator just cannot find the headers itself - this makes code navigation somewhat more complex.
So lets take OpenCL. I include it like this:
#ifdef __APPLE__
#include <OpenCL/cl.h>
#include <OpenCL/opencl.h>
#endif
My app.pro file for qmake has the following inside it:
macx:QMAKE_LFLAGS += -framework OpenCL
And with this it seems to compile. However the two OpenCL #include above in QtCreator are yellow underlined with a tooltip saying "OpenCL/cl.h: No such file or directory".
Now I can see that it compiles successfully as qmake is working out where the frameworks are and appending the paths successfully:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -c -pipe -stdlib=libc++ -g -std=gnu++11 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk -mmacosx-version-min=10.7 -Wall -W -fPIC -DQT_DEPRECATED_WARNINGS -DQT_QML_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I/Users/me/Projects/app -I. -I/Users/me/Qt5.6.2/5.6/clang_64/lib/QtWidgets.framework/Headers -I/Users/me/Qt5.6.2/5.6/clang_64/lib/QtGui.framework/Headers -I/Users/me/Qt5.6.2/5.6/clang_64/lib/QtCore.framework/Headers -I. -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/OpenGL.framework/Headers -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/AGL.framework/Headers -I. -I/Users/me/Qt5.6.2/5.6/clang_64/mkspecs/macx-clang -F/Users/me/Qt5.6.2/5.6/clang_64/lib -o main.o /Users/me/Projects/app/main.cpp
Now if I navigate to the following directory the headers are there and present:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/OpenCL.framework/Versions/A
So I cannot see what is missing.
I have tried to "teach" Qt Creator about this framework directory with combinations of the following, but I havent found something that will work:
macx:QMAKE_LFLAGS += -framework OpenCL
macx:INCLUDEPATH += /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/OpenCL.framework/Versions/A/Headers
macx:QMAKE_LFLAGS += -F/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks
macx:LIBS += -framework OpenCL
I'm struggling to find information about how QtCreator find the system frameworks on a mac and how i get it to start finding them again. Any help would be massively appreciated.
For anybody that has the same problem the answer was actually rather simple in the end.
When you setup the kit in Qt creator (which tells it what compiler and debugger to use amongst other things) you need to be careful with the compiler used. I had two copies of clang on my machine, one was installed in /usr/bin (the system one) and the other was installed inside the XCode app bundle. My kit was using the Xcode installed one as thats where the libraries live. While this compiled just fine, Qt creator for some reason does not hook up the paths to libraries properly. Simply switching this over to using the one in /usr/bin solved it.
Note that i did not explicitly ask it to use the one in the Xcode app bundle, thats just the one that was automatically selected when the project was first opened in Qt creator. So you might have to adjust its default behaviour in order to fix things.
This is my first question on stackoverflow. I've seen a few posts related to openGL on Ubuntu, but none seem to relate to the problem I'm having.
For some reason whenever I try to build my project in eclipse-CDT I get the following console output:
**** Build of configuration Debug for project windows ****
make all
Building file: ../src/windows.cpp
Invoking: GCC C++ Compiler
g++ -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/windows.d" -MT"src/windows.d" -o "src/windows.o" "../src/windows.cpp"
Finished building: ../src/windows.cpp
Building target: windows
Invoking: GCC C++ Linker
g++ -o "windows" ./src/OGdisplay.o ./src/windows.o -lGLEW -lGL -lSDL2
/usr/bin/ld: cannot find -lGL
collect2: error: ld returned 1 exit status
makefile:45: recipe for target 'windows' failed
make: *** [windows] Error 1
**** Build Finished ****
I've installed the mesa-common-Dev package and all the others I could find that have to do with opengl development, but it won't budge. I put: GLEW, GL, and SDL2 in libraries under the GCC C++ linker settings. It doesn't seem to have any issues finding SDL2 and GLEW, but for some reason just can't find GL.
I went to usr/include and can clearly see the GL folder with it's contents as well as SDL2(which it has no issues finding). I've tried the same thing in codeblocks with extremely simple code and get the same result saying it can't find GL.
I'm running Ubuntu 16.04LTS with an nvidia GeForce GTX 1060. I'm also using the NVIDIA Xserver driver version 367.44. Under the nvidia Xserver settings in the OpenGL information sections it says it has version: 4.5.0 NVIDIA 367.44 if that helps. If you need anymore information just let me know, I'm almost certain that it's something simple I'm not thinking of.
Here are my CDT linker settings if it'll let me post a pick:
linker settings screenshot
SOLUTION: I'm not sure it's much of a solution, but I reinstalled NVIDIA X server and it seems to be working fine now. Not sure what was orginally causing it though.
I am trying to set up OpenGL on Eclipse C++. I have followed the steps described in the answer of [1], but, when I do that it appears the following:
Building target: opengltest
Invoking: MacOS X C++ Linker
g++ -L/Developer/SDKs/MacOSX10.5.sdk/usr/X11/lib -L/Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries -framework GLUT -framework OpenGL -framework Cocoa -arch i686 -o "opengltest" ./main.o -lgl -lglu -lglut
ld: library not found for -lglut
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [opengltest] Error 1
I have also changed the include line to:
#include <GLUT/glut.h>
Why is this error appearing?
[1] OpenGL and GLUT in Eclipse on OS X
You followed a tutorial aimed at Linux/BSD developers. In MacOS X you neither use the X11 server not link directly to the OpenGL interface libraries. In MacOS you merely add the OpenGL framework (add -framework OpenGL to the compiler command options). I'm not an active Eclipse user, but I'm pretty sure, it recognized MacOS X frameworks and you can just add the OpenGL framework to it.
GLUT is not part of OpenGL it's an independent library, but it used to be part of the MacOS X OpenGL framework for some time. Recently it was moved into a separate framework.
To add further speed bumps, Apple decided, that they'd put the OpenGL header files not into the canonical place GL/…, but into OpenGL/… so that you'll have to litter your program source text with #ifdef preprocessor statements
#ifdef __APPLE__
#include <OpenGL/gl.h>
#else
#include <GL/gl.h>
#endif
I've recently built libc++ from scratch as my prject needs some features that are not yet implemnted in libstdc++.
I try to compile the hello world program located in src/main.cpp with line
clang -Wall -stdlib=libc++ -std=c++11 -c src/main.cpp -obuild/main.o
and the build suceeds
Then I link it with
clang -lc++ build/main.o -o qasix
and the linking suceeds too.
But when I run the program with
./qasix
I get the following error:
./qasix: symbol lookup error: /usr/local/lib/libc++.so.1: undefined symbol: _ZTVN10__cxxabiv120__si_class_type_infoE
I would like to know why this is occurring and also how to fix it.
I am on Xubuntu 13.10 if that's of any help.
PS: This problem popped up yesterday. Earlier other libc++ programs would compile fine.
This started when I did a debug build of a program with the -g flag and it compiled and ran fine, but all later programs complained about this symbol lookup failure. Please help.
it appears that you need the support library "libc++abi". It provides things like low-level exception support, type_info support, etc.
For Ubuntu (as opposed to Xubuntu), it appears that you can get it here: http://www.ubuntuupdates.org/package/core/saucy/universe/base/libc++abi-dev
Ok, this is just a bit of a fun exercise, but it can't be too hard compiling programmes for some older linux systems, or can it?
I have access to a couple of ancient systems all running linux and maybe it'd be interesting to see how they perform under load. Say as an example we want to do some linear algebra using Eigen which is a nice header-only library. Any chance to compile it on the target system?
user#ancient:~ $ uname -a
Linux local 2.2.16 #5 Sat Jul 8 20:36:25 MEST 2000 i586 unknown
user#ancient:~ $ gcc --version
egcs-2.91.66
Maybe not... So let's compile it on a current system. Below are my attempts, mainly failed ones. Any more ideas very welcome.
Compile with -m32 -march=i386
user#ancient:~ $ ./a.out
BUG IN DYNAMIC LINKER ld.so: dynamic-link.h: 53: elf_get_dynamic_info: Assertion `! "bad dynamic tag"' failed!
Compile with -m32 -march=i386 -static: Runs on all fairly recent kernel versions but fails if they are slightly older with the well known error message
user#ancient:~ $ ./a.out
FATAL: kernel too old
Segmentation fault
This is a glibc error which has a minimum kernel version it supports, e.g. kernel 2.6.4 on my system:
$ file a.out
a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
statically linked, for GNU/Linux 2.6.4, not stripped
Compile glibc myself with support for the oldest kernel possible. This post describes it in more detail but essentially it goes like this
wget ftp://ftp.gnu.org/gnu/glibc/glibc-2.14.tar.bz2
tar -xjf glibc-2.14.tar.bz2
cd glibc-2.14
mkdir build; cd build
../configure --prefix=/usr/local/glibc_32 \
--enable-kernel=2.0.0 \
--with-cpu=i486 --host=i486-linux-gnu \
CC="gcc -m32 -march=i486" CXX="g++ -m32 -march=i486"
make -j 4
make intall
Not sure if the --with-cpu and --host options do anything, most important is to force the use of compiler flags -m32 -march=i486 for 32-bit builds (unfortunately -march=i386 bails out with errors after a while) and --enable-kernel=2.0.0 to make the library compatible with older kernels. Incidentially, during configure I got the warning
WARNING: minimum kernel version reset to 2.0.10
which is still acceptable, I suppose. For a list of things which change with different kernels see ./sysdeps/unix/sysv/linux/kernel-features.h.
Ok, so let's link against the newly compiled glibc library, slightly messy but here it goes:
$ export LIBC_PATH=/usr/local/glibc_32
$ export LIBC_FLAGS=-nostdlib -L${LIBC_PATH} \
${LIBC_PATH}/crt1.o ${LIBC_PATH}/crti.o \
-lm -lc -lgcc -lgcc_eh -lstdc++ -lc \
${LIBC_PATH}/crtn.o
$ g++ -m32 -static prog.o ${LIBC_FLAGS} -o prog
Since we're doing a static compile the link order is important and may well require some trial and error, but basically we learn from what options gcc gives to the linker:
$ g++ -m32 -static -Wl,-v file.o
Note, crtbeginT.o and crtend.o are also linked against which I didn't need for my programmes so I left them out. The output also includes a line like --start-group -lgcc -lgcc_eh -lc --end-group which indicates inter-dependence between the libraries, see this post. I just mentioned -lc twice in the gcc command line which also solves inter-dependence.
Right, the hard work has paid off and now I get
$ file ./prog
./prog: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
statically linked, for GNU/Linux 2.0.10, not stripped
Brilliant I thought, now try it on the old system:
user#ancient:~ $ ./prog
set_thread_area failed when setting up thread-local storage
Segmentation fault
This, again, is a glibc error message from ./nptl/sysdeps/i386/tls.h. I fail to understand the details and give up.
Compile on the new system g++ -c -m32 -march=i386 and link on the old. Wow, that actually works for C and simple C++ programmes (not using C++ objects), at least for the few I've tested. This is not too surprising as all I need from libc is printf (and maybe some maths) of which the interface hasn't changed but the interface to libstdc++ is very different now.
Setup a virtual box with an old linux system and gcc version 2.95. Then compile gcc version 4.x.x ... sorry, but too lazy for that right now ...
???
Have found the reason for the error message:
user#ancient $ ./prog
set_thread_area failed when setting up thread-local storage
Segmentation fault
It's because glibc makes a system call to a function which is only available since kernel 2.4.20. In a way it can be seen as a bug of glibc as it wrongly claims to be compatible with kernel 2.0.10 when it requires at least kernel 2.4.20.
The details:
./glibc-2.14/nptl/sysdeps/i386/tls.h
[...]
/* Install the TLS. */ \
asm volatile (TLS_LOAD_EBX \
"int $0x80\n\t" \
TLS_LOAD_EBX \
: "=a" (_result), "=m" (_segdescr.desc.entry_number) \
: "0" (__NR_set_thread_area), \
TLS_EBX_ARG (&_segdescr.desc), "m" (_segdescr.desc)); \
[...]
_result == 0 ? NULL \
: "set_thread_area failed when setting up thread-local storage\n"; })
[...]
The main thing here is, it calls the assembly function int 0x80 which is a system call to the linux kernel which decides what to do based on the value of eax, which is set to
__NR_set_thread_area in this case and is defined in
$ grep __NR_set_thread_area /usr/src/linux-2.4.20/include/asm-i386/unistd.h
#define __NR_set_thread_area 243
but not in any earlier kernel versions.
So the good news is that point "3. Compiling glibc with --enable-kernel=2.0.0" will probably produce executables which run on all linux kernels >= 2.4.20.
The only chance to make this work with older kernels would be to disable tls (thread-local storage) but which is not possible with glibc 2.14, despite the fact it is offered as a configure option.
The reason you can't compile it on the original system likely has nothing to do with kernel version (it could, but 2.2 isn't generally old enough for that to be a stumbling block for most code). The problem is that the toolchain is ancient (at the very least, the compiler). However, nothing stops you from building a newer version of G++ with the egcs that is installed. You may also encounter problems with glibc once you've done that, but you should at least get that far.
What you should do will look something like this:
Build latest GCC with egcs
Rebuild latest GCC with the gcc you just built
Build latest binutils and ld with your new compiler
Now you have a well-built modern compiler and (most of a) toolchain with which to build your sample application. If luck is not on your side you may also need to build a newer version of glibc, but this is your problem - the toolchain - not the kernel.