I am new to pangolin and trying to compile a 'hello world' code of pangolin on Qt Creator. I have run into this "undefined reference" issue while compiling it. My code is simple :
#include <iostream>
#include <pangolin/pangolin.h>
using namespace std;
int main()
{
pangolin::CreateWindowAndBind("Main",640,480);
return 0;
}
My .pro file looks as following :
QT += core
QT -= gui
TARGET = hellopangolin
CONFIG += c++11
CONFIG -= app_bundle
TEMPLATE = app
SOURCES += main.cpp
INCLUDEPATH += /home/mavbot/Pangolin/include /home/mavbot/Pangolin/build/src/include
LIBS += -L "/home/mavbot/Pangolin/build/src"
-lpangolin \
LIBS += -lGLEW \
-lGL \
-lEGL
I have successfully compiled and build the pangolin library as the example programs run smoothly on my system.I ran a ldd on the executable of the examples and found the dependent libraries and tried to link them in QT Creator. I am new to OpenGL too. The error I run into is :
error: undefined reference to `pangolin::CreateWindowAndBind(std::__cxx11::basic_string, std::allocator >, int, int, pangolin::Params const&)'
I build pangolin as follows :
git clone https://github.com/stevenlovegrove/Pangolin.git
cd Pangolin
mkdir build
cd build
cmake ..
make -j8
EDIT 2: After Botje's suggestion, inserting the / after the library path helped it to compile. However now I have a run time error :
/home/mavbot/Documents/qtcodes/build-hellopangolin-Desktop-Debug/hellopangolin: error while loading shared libraries: libpangolin.so: cannot open shared object file: No such file or directory
EDIT 3:
-rwxrwxr-x 1 mavbot mavbot 2333648 Mar 10 23:55 /home/mavbot/Pangolin/build/src/libpangolin.so
linux-vdso.so.1 => (0x00007ffedc5b8000)
libGL.so.1 => /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1 (0x00007f05e3401000)
libGLEW.so.1.13 => /usr/lib/x86_64-linux-gnu/libGLEW.so.1.13 (0x00007f05e317e000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f05e2e44000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f05e2c3c000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f05e2a1f000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f05e269d000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f05e2394000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f05e217e000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f05e1db4000)
/lib64/ld-linux-x86-64.so.2 (0x00007f05e3a5a000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f05e1b9a000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f05e1971000)
libxcb-dri3.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0 (0x00007f05e176e000)
libxcb-present.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-present.so.0 (0x00007f05e156b000)
libxcb-sync.so.1 => /usr/lib/x86_64-linux-gnu/libxcb-sync.so.1 (0x00007f05e1364000)
libxshmfence.so.1 => /usr/lib/x86_64-linux-gnu/libxshmfence.so.1 (0x00007f05e1161000)
libglapi.so.0 => /usr/lib/x86_64-linux-gnu/libglapi.so.0 (0x00007f05e0f30000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f05e0d1e000)
libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007f05e0b1b000)
libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f05e0915000)
libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007f05e0713000)
libxcb-glx.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0 (0x00007f05e04fa000)
libxcb-dri2.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0 (0x00007f05e02f5000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f05e00d3000)
libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007f05dfecd000)
libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 (0x00007f05dfcbb000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f05dfab7000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f05df8b3000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f05df6ad000)
As /home/mavbot/Pangolin/build/src is not a default place to look for libraries, you have to inform the dynamic linker (ld.so) to look there.
You can do this by:
either setting the environment variable LD_LIBRARY_PATH=/home/mavbot/Pangolin/build/src every time you run your program, or
compiling your program with a "runpath". This will instruct ld.so to look there first. The flag is as follows:
-Wl,-rpath=/home/mavbot/Pangolin/build/src
or just installing pangolin globally, where the linker looks by default (check the contents of /etc/ld.so.conf and/or /etc/ld.so.conf.d/* for the default paths.
Related
When I check with ldd -v MyApp, I get the list of dependencies:
Version information:
./MyApp:
libgcc_s.so.1 (GCC_3.0) => /home/user/cless/libgcc_s.so.1
libdl.so.2 (GLIBC_2.2.5) => /usr/local/lib64/glibc-test/lib/libdl.so.2
libpthread.so.0 (GLIBC_2.3.2) => /usr/local/lib64/glibc-test/lib/libpthread.so.0
libpthread.so.0 (GLIBC_2.2.5) => /usr/local/lib64/glibc-test/lib/libpthread.so.0
libc.so.6 (GLIBC_2.14) => /usr/local/lib64/glibc-test/lib/libc.so.6
libc.so.6 (GLIBC_2.8) => /usr/local/lib64/glibc-test/lib/libc.so.6
libc.so.6 (GLIBC_2.3) => /usr/local/lib64/glibc-test/lib/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /usr/local/lib64/glibc-test/lib/libc.so.6
libstdc++.so.6 (GLIBCXX_3.4.14) => /home/user/cless/libstdc++.so.6
libstdc++.so.6 (GLIBCXX_3.4.9) => /home/user/cless/libstdc++.so.6
libstdc++.so.6 (GLIBCXX_3.4.19) => /home/user/cless/libstdc++.so.6
libstdc++.so.6 (GLIBCXX_3.4.11) => /home/user/cless/libstdc++.so.6
libstdc++.so.6 (CXXABI_1.3) => /home/user/cless/libstdc++.so.6
libstdc++.so.6 (GLIBCXX_3.4.20) => /home/user/cless/libstdc++.so.6
libstdc++.so.6 (GLIBCXX_3.4.15) => /home/user/cless/libstdc++.so.6
libstdc++.so.6 (GLIBCXX_3.4) => /home/user/cless/libstdc++.so.6
But, how can I know which exact version of libstdc++.so.6 do I need? Is it libstdc++.so.6.0.13? Or is libstdc++.so.6.0.20?
What should I do to know that?
Can I be sure looking my version of GCC compiler, let say, 4.4.7?
My GUI code compiles fine but when I click on a button which does some computation, I get the following error :
./main_exe: symbol lookup error: ./main_exe: undefined symbol: clfftInitSetupData
I don't understand given that nm -D output :
nm -D /usr/local/lib64/libclFFT.so | grep clfftInitSetupData
00000000000acfb0 T clfftInitSetupData
So this function clfftInitSetupData should be known by the executable main.exe.
Here is the main part of the Makefile used :
OPENCL = /opt/AMDAPPSDK-3.0
INC_OPENCL = -I$(OPENCL)/include
INC_GSL = -I/usr/include/gsl
INC_CLFFT = -I/opt/clFFT/src/include
INCPATH = $(INC_OPENCL) $(INC_GSL) $(INC_CLFFT) -I/usr/share/qt4/mkspecs/linux-g++ -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtOpenGL -I/usr/include/qt4 -I.
LINK = g++
LFLAGS = -Wl,-O3
LIBS = -L/usr/local/lib64 -lclFFT -L/usr/lib -lgsl -lgslcblas -lQtGui -lQtCore -lQtOpenGL -lpthread -L$(OPENCL)/lib/x86_64 -lOpenCL -lglut -lGL -lGLEW -lGLU -L/usr/lib -lpng
and ldd on the executable gives :
linux-vdso.so.1 (0x00007ffe3f96b000)
libclFFT.so.2 => /lib/x86_64-linux-gnu/libclFFT.so.2 (0x00007fbd53bbf000)
libgsl.so.23 => /lib/x86_64-linux-gnu/libgsl.so.23 (0x00007fbd53936000)
libgslcblas.so.0 => /lib/x86_64-linux-gnu/libgslcblas.so.0 (0x00007fbd538f5000)
libQtGui.so.4 => /lib/x86_64-linux-gnu/libQtGui.so.4 (0x00007fbd52dc0000)
libQtCore.so.4 => /lib/x86_64-linux-gnu/libQtCore.so.4 (0x00007fbd52ab6000)
libQtOpenGL.so.4 => /lib/x86_64-linux-gnu/libQtOpenGL.so.4 (0x00007fbd529a8000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fbd52987000)
libOpenCL.so.1 => /usr/local/cuda/targets/x86_64-linux/lib/libOpenCL.so.1 (0x00007fbd5277f000)
libglut.so => not found
libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x00007fbd526eb000)
libGLEW.so => not found
libGLU.so.1 => /lib/x86_64-linux-gnu/libGLU.so.1 (0x00007fbd52678000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00007fbd52651000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fbd524cd000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fbd5234a000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fbd52330000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbd5216f000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fbd52168000)
libfontconfig.so.1 => /lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007fbd52122000)
libaudio.so.2 => /lib/x86_64-linux-gnu/libaudio.so.2 (0x00007fbd51f08000)
libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007fbd51de9000)
libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16 (0x00007fbd51db0000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fbd51b92000)
libfreetype.so.6 => /lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007fbd51ad4000)
libgobject-2.0.so.0 => /lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007fbd51a7e000)
libSM.so.6 => /lib/x86_64-linux-gnu/libSM.so.6 (0x00007fbd51a73000)
libICE.so.6 => /lib/x86_64-linux-gnu/libICE.so.6 (0x00007fbd51856000)
libXrender.so.1 => /lib/x86_64-linux-gnu/libXrender.so.1 (0x00007fbd5164c000)
libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6 (0x00007fbd5143a000)
libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007fbd512f7000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fbd512ed000)
/lib64/ld-linux-x86-64.so.2 (0x00007fbd53d6d000)
libGLX.so.0 => /lib/x86_64-linux-gnu/libGLX.so.0 (0x00007fbd512b9000)
libGLdispatch.so.0 => /lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007fbd511fc000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007fbd511bf000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007fbd511b4000)
libXt.so.6 => /lib/x86_64-linux-gnu/libXt.so.6 (0x00007fbd51149000)
libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007fbd50f45000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fbd50ed1000)
libffi.so.6 => /lib/x86_64-linux-gnu/libffi.so.6 (0x00007fbd50ec7000)
libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007fbd50eab000)
libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007fbd50e81000)
libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007fbd50c7b000)
If someone could see what's wrong. Maybe I take into account 2 similar libraries, I don't know for the moment.
You showed nm output for /usr/local/lib64/ libclFFT.so yet ldd says it found /lib/x86_64-linux-gnu/ libclFFT.so.2.
Set the LD_LIBRARY_PATH environment variable to /usr/local/lib64 when you run main to make sure it looks there first. Alternatively, add it to your /etc/ld.so.conf.d tree (and re-run ldconfig).
My build command
g++ -g -m64 -D_FILE_OFFSET_BITS=64 -fPIC -I./curl-7.60.0/include -I./jsoncpp-src-0.5.0/include/ ./jsoncpp-src-0.5.0/libs/linux-gcc-4.4.7/libjson_linux-gcc-4.4.7_libmt.so ./curl-7.60.0/lib/.libs/libcurl.so.4.5.0 tests.cpp -otests
The .so file exsists
-rwxr-xr-x. 1 pswluna developer 529763 2018-05-30 18:48 ./curl-7.60.0/lib/.libs/libcurl.so.4.5.0
But ldd result is... (please see the 3rd line.)
linux-vdso.so.1 => (0x00007ffd4f5f1000)
./jsoncpp-src-0.5.0/libs/linux-gcc-4.4.7/libjson_linux-gcc-4.4.7_libmt.so (0x00007f833daec000)
libcurl.so.4 => /usr/lib64/libcurl.so.4 (0x0000003b0e600000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003eb5c00000)
libm.so.6 => /lib64/libm.so.6 (0x0000003eab000000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003eb4c00000)
libc.so.6 => /lib64/libc.so.6 (0x0000003eaac00000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003eab400000)
libidn.so.11 => /lib64/libidn.so.11 (0x0000003ec0c00000)
libldap-2.4.so.2 => /lib64/libldap-2.4.so.2 (0x0000003461200000)
librt.so.1 => /lib64/librt.so.1 (0x0000003eac000000)
libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x0000003088600000)
libkrb5.so.3 => /lib64/libkrb5.so.3 (0x0000003087a00000)
libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x0000003088a00000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x0000003eb7000000)
libz.so.1 => /lib64/libz.so.1 (0x0000003eabc00000)
libssl3.so => /usr/lib64/libssl3.so (0x0000003ebb800000)
libsmime3.so => /usr/lib64/libsmime3.so (0x0000003ebbc00000)
libnss3.so => /usr/lib64/libnss3.so (0x0000003eba800000)
libnssutil3.so => /usr/lib64/libnssutil3.so (0x0000003eb9800000)
libplds4.so => /lib64/libplds4.so (0x0000003eb9400000)
libplc4.so => /lib64/libplc4.so (0x0000003eb9c00000)
libnspr4.so => /lib64/libnspr4.so (0x0000003eba000000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003eab800000)
libssh2.so.1 => /usr/lib64/libssh2.so.1 (0x0000003089a00000)
/lib64/ld-linux-x86-64.so.2 (0x0000003eaa800000)
liblber-2.4.so.2 => /lib64/liblber-2.4.so.2 (0x0000003ebe800000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003ead000000)
libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x0000003466800000)
libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x0000003088200000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x0000003eb7400000)
libssl.so.10 => /usr/lib64/libssl.so.10 (0x0000003088e00000)
libcrypto.so.10 => /usr/lib64/libcrypto.so.10 (0x0000003087e00000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x0000003460600000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x0000003086200000)
libfreebl3.so => /lib64/libfreebl3.so (0x000000345f600000)
Please help me...................
g++ -g -m64 -D_FILE_OFFSET_BITS=64 -fPIC -I./curl-7.60.0/include -I./jsoncpp-src-0.5.0/include/ ./jsoncpp-src-0.5.0/libs/linux-gcc-4.4.7/libjson_linux-gcc-4.4.7_libmt.so ./curl-7.60.0/lib/.libs/libcurl.so.4.5.0 tests.cpp -otests
This command does link the library you want: ./curl-7.60.0/lib/.libs/libcurl.so.4.5.0, but it doesn't arrange for that library to be used at runtime.
Here is the command you want:
g++ -g -m64 -I./curl-7.60.0/include -I./jsoncpp-src-0.5.0/include/ \
tests.cpp \
-L./jsoncpp-src-0.5.0/libs/linux-gcc-4.4.7 -ljson_linux-gcc-4.4.7_libmt \
-L./curl-7.60.0/lib/.libs -l:libcurl.so.4.5.0 \
-Wl,-rpath=$(pwd)/jsoncpp-src-0.5.0/libs/linux-gcc-4.4.7 \
-Wl,-rpath=$(pwd)/curl-7.60.0/lib/.libs \
-otests
Explanation:
You want to use -rpath to tell the dynamic loader where it should search for libraries at runtime
-D_FILE_OFFSET_BITS=64 only makes sense when you build a 32-bit binary on a 64-bit OS, but you aren't doing that
-fPIC is completely unnecessary when you are building main executable.
The order of sources and libraries on command line matters, your order is wrong.
I am running this command --
/usr/bin/c++ CMakeFiles/XYZ.dir/test/XYZ.cpp.o CMakeFiles/XYZ.dir/test/TempDir.cpp.o
-o XYZ libXYZMaster.so -lboost_filesystem -lboost_system
/usr/lib/x86_64-linux-gnu/libboost_unit_test_framework.so -lboost_random
-lboost_iostreams -lboost_thread -ldw -lunwind
-Wl,-rpath,/home/user885/untitled/build
But I get this linker error --
libXYZMaster.so: undefined reference to `_Ux86_64_step'
libXYZMaster.so: undefined reference to `_Ux86_64_init_local'
libXYZMaster.so: undefined reference to `_Ux86_64_get_proc_name'
libXYZMaster.so: undefined reference to `_Ux86_64_get_reg'
When I do nm -D I do see the symbols defined -
$ nm -D /usr/lib/x86_64-linux-gnu/libunwind.so | grep -P "_step|init_local|get_proc_name|get_reg"
00000000000031d0 T _ULx86_64_get_proc_name
0000000000003370 T _ULx86_64_get_reg
0000000000004510 T _ULx86_64_init_local
0000000000004d20 T _ULx86_64_step
Also, ldd of libXYZMaster.so indicates that the libunwind is linked --
linux-vdso.so.1 => (0x00007ffd58f4a000)
libdw.so.1 => /usr/lib/x86_64-linux-gnu/libdw.so.1 (0x00007ff614bac000)
libunwind.so.8 => /usr/lib/x86_64-linux-gnu/libunwind.so.8 (0x00007ff614991000)
libboost_system.so.1.58.0 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.58.0 (0x00007ff61478d000)
libboost_filesystem.so.1.58.0 => /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.58.0 (0x00007ff614575000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ff6141ec000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff613e22000)
libelf.so.1 => /usr/lib/x86_64-linux-gnu/libelf.so.1 (0x00007ff613c0a000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff613a06000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007ff6137ec000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007ff6135ca000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007ff6133ba000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff615084000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff61319d000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff612f86000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff612c7d000)
For future reference, it is because I had not #defined UNW_LOCAL_ONLY before including ... Leaving it undefined lead to different function signature getting picked (at random perhaps).
http://www.nongnu.org/libunwind/man/libunwind(3).html
I'm trying to compile a simple test program from http://open.gl/introduction :
#include <GLFW/glfw3.h>
#include <thread>
int main()
{
glfwInit();
std::this_thread::sleep_for(std::chrono::seconds(1));
glfwTerminate();
}
I use the following to compile:
>> g++ -c tutorial01.cpp -o tutorial01.o -std=c++11
>> g++ tutorial01.o -o tutorial01 -lglfw3 -lGL -lXrandr -lX11 -lXi -lGLEW
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libGL.so: undefined reference to `_glapi_tls_Dispatch'
collect2: error: ld returned 1 exit status
Here are some extra info about the problem:
>> readlink -f "/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libGL.so"
/usr/lib/x86_64-linux-gnu/libGL.so.1.2.0
>> nm -D /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 | grep _glapi_tls_Dispatch
U _glapi_tls_Dispatch
>> ldd /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0
linux-vdso.so.1 (0x00007fff0b200000)
libglapi.so.0 => /usr/lib/x86_64-linux-gnu/libglapi.so.0 (0x00007ff437f80000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007ff437d68000)
libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007ff437b60000)
libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007ff437958000)
libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007ff437750000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007ff437410000)
libxcb-glx.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0 (0x00007ff4371f8000)
libxcb-dri2.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0 (0x00007ff436ff0000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007ff436dd0000)
libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007ff436bc8000)
libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 (0x00007ff4369b8000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff4366b0000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff436490000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff436288000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff435ed8000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007ff435cd0000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007ff435ac8000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff438428000)
>> nm -D /usr/lib/x86_64-linux-gnu/libglapi.so.0 |grep _glapi_tls_Dispatch
0000000000000000 D _glapi_tls_Dispatch
The symbol _glapi_tls_Dispatch is defined in libglapi.so, ligGL.so depends to libglapi.so, so why does the link fail?
Does anyone have a clue ?
Did a quick search of libglfw3-dev package and it lists the library file as -lglfw not -lglfw3 on my system. Dunno if that helps or not.
apt-file search libglfw | grep -v doc
libglfw-dev: /usr/lib/x86_64-linux-gnu/libglfw.a
libglfw-dev: /usr/lib/x86_64-linux-gnu/libglfw.so
libglfw-dev: /usr/lib/x86_64-linux-gnu/pkgconfig/libglfw.pc
libglfw2: /usr/lib/x86_64-linux-gnu/libglfw.so.2
libglfw3: /usr/lib/x86_64-linux-gnu/libglfw.so.3
libglfw3: /usr/lib/x86_64-linux-gnu/libglfw.so.3.1
libglfw3-dev: /usr/lib/x86_64-linux-gnu/libglfw.so