I'm trying to debug my OpenGl project with gDEBugger, but unfortunately gDEBugger is not even starting:
~/bin/gDEBugger581-x86_64> ./gDEBugger-bin
libGL error: failed to load driver: swrast
libGL error: Try again with LIBGL_DEBUG=verbose for more details.
Segmentation fault
~/bin/gDEBugger581-x86_64> LIBGL_DEBUG=verbose ./gDEBugger-bin
libGL: screen 0 does not appear to be DRI2 capable
libGL: OpenDriver: trying /usr/lib64/dri/updates/tls/swrast_dri.so
libGL: OpenDriver: trying /usr/lib64/dri/updates/swrast_dri.so
libGL error: dlopen /usr/lib64/dri/updates/swrast_dri.so failed (/usr/lib64/dri/updates /swrast_dri.so: cannot open shared object file: No such file or directory)
libGL: OpenDriver: trying /usr/lib64/dri/tls/swrast_dri.so
libGL: OpenDriver: trying /usr/lib64/dri/swrast_dri.so
libGL error: dlopen /usr/lib64/dri/swrast_dri.so failed (/usr/lib64/dri/swrast_dri.so: undefined symbol: _glapi_tls_Dispatch)
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast
Segmentation fault
this happens with the last gremedy version (5.8.1), the last AMD version (6.2.4) and the latest CodeXL version (CodeXL doesn't crash, but the same error appears non the less and debugging doesn't work).
I'm on OpenSuse 13.1, I have a NVIDIA card and the latest drivers installed. Other OpenGL programms work just fine. So far I've tried to reinstall NVIDIA drivers, reinstall all MESA packages, update CUDA from 5.5 to 6.5, checked that all mesa packages are installed from the standard suse repo and ran ldd:
~/bin/gDEBugger581-x86_64> ldd gDEBugger-bin
linux-vdso.so.1 (0x00007fffe9ffe000)
libGRBaseTools.so => ./libGRBaseTools.so (0x00007f41df93e000)
libGROSWrappers.so => ./libGROSWrappers.so (0x00007f41df6cc000)
libGRAPIClasses.so => ./libGRAPIClasses.so (0x00007f41df358000)
libGRProcessDebugger.so => ./libGRProcessDebugger.so (0x00007f41df123000)
libGRApiFunctions.so => ./libGRApiFunctions.so (0x00007f41deedf000)
libGRApplicationComponents.so => ./libGRApplicationComponents.so (0x00007f41debce000)
libgDEBuggerAppCode.so => ./libgDEBuggerAppCode.so (0x00007f41de5b0000)
libwx_base-2.8.so.0 => ./libwx_base-2.8.so.0 (0x00007f41de29e000)
libwx_gtk2_core-2.8.so.0 => ./libwx_gtk2_core-2.8.so.0 (0x00007f41ddcd9000)
libwx_gtk2_html-2.8.so.0 => ./libwx_gtk2_html-2.8.so.0 (0x00007f41dda2f000)
libwx_gtk2_adv-2.8.so.0 => ./libwx_gtk2_adv-2.8.so.0 (0x00007f41dd753000)
libwx_gtk2_aui-2.8.so.0 => ./libwx_gtk2_aui-2.8.so.0 (0x00007f41dd4e2000)
libwx_gtk2_gl-2.8.so.0 => ./libwx_gtk2_gl-2.8.so.0 (0x00007f41dd2d5000)
libwx_gtk2_stc-2.8.so.0 => ./libwx_gtk2_stc-2.8.so.0 (0x00007f41dcfcb000)
libfreeimage.so.3 => ./libfreeimage.so.3 (0x00007f41dcc35000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f41dc92d000)
libm.so.6 => /lib64/libm.so.6 (0x00007f41dc62a000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f41dc413000)
libc.so.6 => /lib64/libc.so.6 (0x00007f41dc065000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f41dbe61000)
librt.so.1 => /lib64/librt.so.1 (0x00007f41dbc59000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f41dba3b000)
libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007f41db6fd000)
libz.so.1 => /lib64/libz.so.1 (0x00007f41db4e7000)
libGL.so.1 => /usr/X11R6/lib64/libGL.so.1 (0x00007f41db19b000)
libgtk-x11-2.0.so.0 => /usr/lib64/libgtk-x11-2.0.so.0 (0x00007f41dab5c000)
libgdk-x11-2.0.so.0 => /usr/lib64/libgdk-x11-2.0.so.0 (0x00007f41da8a7000)
libatk-1.0.so.0 => /usr/lib64/libatk-1.0.so.0 (0x00007f41da683000)
libgio-2.0.so.0 => /usr/lib64/libgio-2.0.so.0 (0x00007f41da31c000)
libpangoft2-1.0.so.0 => /usr/lib64/libpangoft2-1.0.so.0 (0x00007f41da108000)
libgdk_pixbuf-2.0.so.0 => /usr/lib64/libgdk_pixbuf-2.0.so.0 (0x00007f41d9ee7000)
libpango-1.0.so.0 => /usr/lib64/libpango-1.0.so.0 (0x00007f41d9c9b000)
libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007f41d9a09000)
libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00007f41d97cc000)
libgobject-2.0.so.0 => /usr/lib64/libgobject-2.0.so.0 (0x00007f41d957b000)
libgmodule-2.0.so.0 => /usr/lib64/libgmodule-2.0.so.0 (0x00007f41d9377000)
libgthread-2.0.so.0 => /usr/lib64/libgthread-2.0.so.0 (0x00007f41d9175000)
libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007f41d8e72000)
libXinerama.so.1 => /usr/lib64/libXinerama.so.1 (0x00007f41d8c6f000)
libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x00007f41d8a69000)
libSM.so.6 => /usr/lib64/libSM.so.6 (0x00007f41d8861000)
libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x00007f41d85e2000)
/lib64/ld-linux-x86-64.so.2 (0x00007f41dfb49000)
libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007f41d83c3000)
libnvidia-tls.so.340.32 => /usr/lib64/tls/libnvidia-tls.so.340.32 (0x00007f41d81c0000)
libnvidia-glcore.so.340.32 => /usr/lib64/libnvidia-glcore.so.340.32 (0x00007f41d55ad000)
libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007f41d539b000)
libpangocairo-1.0.so.0 => /usr/lib64/libpangocairo-1.0.so.0 (0x00007f41d518e000)
libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00007f41d4f88000)
libcairo.so.2 => /usr/lib64/libcairo.so.2 (0x00007f41d4c69000)
libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x00007f41d4a5f000)
libXi.so.6 => /usr/lib64/libXi.so.6 (0x00007f41d484f000)
libXrandr.so.2 => /usr/lib64/libXrandr.so.2 (0x00007f41d4645000)
libXcursor.so.1 => /usr/lib64/libXcursor.so.1 (0x00007f41d443a000)
libXcomposite.so.1 => /usr/lib64/libXcomposite.so.1 (0x00007f41d4237000)
libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x00007f41d4034000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f41d3e10000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f41d3bf9000)
libharfbuzz.so.0 => /usr/lib64/libharfbuzz.so.0 (0x00007f41d39a6000)
libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007f41d3769000)
libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007f41d353f000)
libffi.so.4 => /usr/lib64/libffi.so.4 (0x00007f41d3337000)
libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x00007f41d30d1000)
libICE.so.6 => /usr/lib64/libICE.so.6 (0x00007f41d2eb5000)
libuuid.so.1 => /usr/lib64/libuuid.so.1 (0x00007f41d2cb0000)
libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007f41d2aac000)
libpixman-1.so.0 => /usr/lib64/libpixman-1.so.0 (0x00007f41d2803000)
libEGL.so.1 => /usr/X11R6/lib64/libEGL.so.1 (0x00007f41d24fa000)
libxcb-shm.so.0 => /usr/lib64/libxcb-shm.so.0 (0x00007f41d22f7000)
libxcb-render.so.0 => /usr/lib64/libxcb-render.so.0 (0x00007f41d20ed000)
libgraphite2.so.3 => /usr/lib64/libgraphite2.so.3 (0x00007f41d1ed1000)
libnvidia-glsi.so.340.32 => /usr/lib64/libnvidia-glsi.so.340.32 (0x00007f41d1c49000)
I noticed, that when running my own program with LIBGL_DEBUG=verbose there is not libGL output at all. I'm using glfw 2.7 and glew 1.9 if it matters. glut apps work.
I suppose that gDEBugger has a different way to find and load libGL and somehow it ends up using the mesa one and not the nvidia one. but my knowledge of mesa and nvidia driver and the workings of it are quite limited.
edit:
new information:
strace -e open ./gDEBugger-bin 2>&1 | grep libGL.so
open("./tls/x86_64/libGL.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("./tls/libGL.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("./x86_64/libGL.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("./libGL.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib64/mpi/gcc/openmpi/lib64/libGL.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/home/damdam/bin/pgmodeler/libGL.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/X11R6/lib64/libGL.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/usr/X11R6/lib64/libGL.so.340.32", O_RDONLY) = 3
open("/usr/X11R6/lib64/libGL.so.340.32", O_RDONLY) = 3
open("/usr/X11R6/lib64/libGL.so.340.32", O_RDONLY) = 4
open("/usr/lib64/libGL.so.1", O_RDONLY|O_CLOEXEC) = 7
open("/usr/X11R6/lib64/libGL.so.340.32", O_RDONLY) = 7
open("/usr/lib64/libGL.so.1", O_RDONLY) = 7
for comparison, this is the same for a working program: http://paste.opensuse.org/76645738
and this is the full output (without grep): http://paste.opensuse.org/8336779
i tried to setup the following links in /usr/lib64/:
libGLESv1_CM.so -> /usr/X11R6/lib64/libGLES
libGLESv1_CM.so.1 -> /usr/X11R6/lib64/libGL
libGLESv1_CM.so.1.1.0 -> /usr/X11R6/lib64/l
libGLESv2.so -> /usr/X11R6/lib64/libGLESv2.
libGLESv2.so.2 -> /usr/X11R6/lib64/libGLESv
libGLESv2.so.2.0.0 -> /usr/X11R6/lib64/libG
libGL.so -> /usr/X11R6/lib64/libGL.so
libGL.so.1 -> /usr/X11R6/lib64/libGL.so
libGL.so.1.2 -> /usr/X11R6/lib64/libGL.so
libGL.so.1.2.0 -> /usr/X11R6/lib64/libGL.so
after that the behaviour changed, the program crashed with a segfault and not printing anything.
edit:
new information
the gremedy gDEBugger (5.8.1) doesn't load /usr/lib64/libGL.so any more when
export LIBGL_DRIVERS_PATH="/usr/X11R6/lib64/"
it just crashes. so my guess is now, that it knew about the correct libGL all the time, but couldn't load it. either there is something strange with my system, or i'm the first reporting about this problem.
I had the same problem with the same distro, same release. Eventually I traced it to the environment variable LD_LIBRARY_PATH.
I had added /usr/lib/ and /usr/lib64/ to LD_LIBRARY_PATH to try to resolve a linking problem. It seems including those directories in LD_LIBRARY_PATH meant /usr/lib64/libGL.so.1 from the package Mesa-libGL1 hid /usr/X11R6/lib64/libGL.so.1 from the package x11-video-nvidiaG02.
Re-exporting LD_LIBRARY_PATH without those two directories had libGL sorted out and working again.
The error messages indicate that for some reason gDEBugger dynamically links a Mesa variant of libGL.so (only Mesa tries to talk the DRI protocol). With your NVidia GPU in the system and I presume the NVidia proprietary drivers being installed and configured as well, this indicates, something is seriously off.
The other possibility is, that you're don't have the NVidia proprietary drivers installed at all and are running completely off Mesa. The problem is, that the NVidia GPU support of Mesa is only rudimentary for any GPU built past 2005.
Note that if you're using the NVidia proprietary drivers you don't need Mesa being installed at all (although having it and using the Mesa libGL.so as linking target for your programs, even if the NVidia libGL.so is used at runtime is quite sensible).
Related
I installed torch on my machine to run the latest onnxruntime tests and got this error.
ImportError: /usr/local/cuda-10.0/lib64/libcublas.so.10: version
`libcublas.so.10' not found (required by
/home/users/username/.local/lib/python3.8/site-packages/torch/lib/libtorch_cuda.so)
But this file does exist and I've made sure with command
ll /usr/local/cuda-10.0/lib64/libcublas.so.10
lrwxrwxrwx 1 root root 44 Dec 20 11:46 /usr/local/cuda-10.0/lib64/libcublas.so.10 -> /usr/local/cuda-10.0/lib64/libcublas.so.10.0
I've checked LD_LIBRARY_PATH and found that /usr/local/cuda-10.0/lib64/ is already in it. I've tried to put it to the front of LD_LIBRARY_PATH and still not working.
I've also tried to use ldd to see the lib file connection and did not get much info.
ldd /home/users/username/.local/lib/python3.8/site-packages/torch/lib/libtorch_cuda.so
/home/users/username/.local/lib/python3.8/site-packages/torch/lib/libtorch_cuda.so: /usr/local/cuda-10.0/lib64/libcublas.so.10: version `libcublas.so.10' not found (required by /home/users/username/.local/lib/python3.8/site-packages/torch/lib/libtorch_cuda.so)
linux-vdso.so.1 => (0x00007ffffb33e000)
libc10_cuda.so => /home/users/username/.local/lib/python3.8/site-packages/torch/lib/libc10_cuda.so (0x00007fedb38ae000)
libcudart-80664282.so.10.2 => /home/users/username/.local/lib/python3.8/site-packages/torch/lib/libcudart-80664282.so.10.2 (0x00007fedb362d000)
libnvToolsExt-3965bdd0.so.1 => /home/users/username/.local/lib/python3.8/site-packages/torch/lib/libnvToolsExt-3965bdd0.so.1 (0x00007fedb3423000)
libpthread.so.0 => /usr/lib64/libpthread.so.0 (0x00007fedb3207000)
libc10.so => /home/users/username/.local/lib/python3.8/site-packages/torch/lib/libc10.so (0x00007fedb2f77000)
libtorch_cpu.so => /home/users/username/.local/lib/python3.8/site-packages/torch/lib/libtorch_cpu.so (0x00007fed9a500000)
libm.so.6 => /usr/lib64/libm.so.6 (0x00007fed9a1fe000)
libdl.so.2 => /usr/lib64/libdl.so.2 (0x00007fed99ffa000)
libcublas.so.10 => /usr/local/cuda-10.0/lib64/libcublas.so.10 (0x00007fed95a64000)
librt.so.1 => /usr/lib64/librt.so.1 (0x00007fed9585c000)
libstdc++.so.6 => /usr/local/gcc-5.4.0/lib64/libstdc++.so.6 (0x00007fed954e1000)
libgcc_s.so.1 => /usr/local/gcc-5.4.0/lib64/libgcc_s.so.1 (0x00007fed952ca000)
libc.so.6 => /usr/lib64/libc.so.6 (0x00007fed94efc000)
/lib64/ld-linux-x86-64.so.2 (0x00007fede3d1e000)
libgomp-a34b3233.so.1 => /home/users/username/.local/lib/python3.8/site-packages/torch/lib/libgomp-a34b3233.so.1 (0x00007fed94cd2000)
Turns out it was because I set the LD_LIBRARY and caused this issue.
I searched the local files and found there are multiple places that have this file:
...
/usr/local/cuda-10.0/lib64/libcublas.so.10
/home/users/username/.local/lib/python3.8/site-packages/torch/lib/libcublas.so.10
So it is because I have /usr/local/cuda-10.0/lib64/libcublas.so.10 this softlink in my system, it used this instead of its own lib file. After I removed this softlink, it worked.
[UPDATE] Upgrading to python 2.7.6 and Qt 4.8.7 appears to make this problem go away and JPEG support is provided. Whereas before creating a QPixmap object using a path to a .jpeg/.jpg file would produce an object for which isNull() was always True, now I get a valid QPixmap object.
The platform in question is a CentOS 7.2 system with KDE4 as the default desktop environment. Qt 4.8.5 is installed along with PySide 1.2.2. JPEG support seems to be missing for some reason.
>>> from PySide import QtGui
>>> pprint(QtGui.QImageReader.supportedImageForamts())
[PySide.QtCore.QByteArray('BW'),
PySide.QtCore.QByteArray('EPS'),
PySide.QtCore.QByteArray('EPSF'),
PySide.QtCore.QByteArray('EPSI'),
PySide.QtCore.QByteArray('EXR'),
PySide.QtCore.QByteArray('PCX'),
PySide.QtCore.QByteArray('PSD'),
PySide.QtCore.QByteArray('RAS'),
PySide.QtCore.QByteArray('RGB'),
PySide.QtCore.QByteArray('RGBA'),
PySide.QtCore.QByteArray('SGI'),
PySide.QtCore.QByteArray('TGA'),
PySide.QtCore.QByteArray('XCF'),
PySide.QtCore.QByteArray('bmp'),
PySide.QtCore.QByteArray('bw'),
PySide.QtCore.QByteArray('dds'),
PySide.QtCore.QByteArray('eps'),
PySide.QtCore.QByteArray('epsf'),
PySide.QtCore.QByteArray('epsi'),
PySide.QtCore.QByteArray('exr'),
PySide.QtCore.QByteArray('jp2'),
PySide.QtCore.QByteArray('pbm'),
PySide.QtCore.QByteArray('pcx'),
PySide.QtCore.QByteArray('pgm'),
PySide.QtCore.QByteArray('pic'),
PySide.QtCore.QByteArray('png'),
PySide.QtCore.QByteArray('ppm'),
PySide.QtCore.QByteArray('psd'),
PySide.QtCore.QByteArray('ras'),
PySide.QtCore.QByteArray('rgb'),
PySide.QtCore.QByteArray('rgba'),
PySide.QtCore.QByteArray('sgi'),
PySide.QtCore.QByteArray('tga'),
PySide.QtCore.QByteArray('xbm'),
PySide.QtCore.QByteArray('xcf'),
PySide.QtCore.QByteArray('xpm'),
PySide.QtCore.QByteArray('xv')]
As you can see there is no JPEG support listed. The Qt imageformats contains:
libqgif.so
libqico.so
libqjpeg.so
libqmng.so
libqsvg.so
libqtga.so
libqtiff.so
Doing an ldd on libqjpeg.so yields:
linux-vdso.so.1 => (0x00007ffc43530000)
libQtGui.so.4 => /lib64/libQtGui.so.4 (0x00007f2c11977000)
libQtCore.so.4 => /lib64/libQtCore.so.4 (0x00007f2c1148c000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f2c1126f000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f2c10f67000)
libm.so.6 => /lib64/libm.so.6 (0x00007f2c10c65000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f2c10a4e000)
libc.so.6 => /lib64/libc.so.6 (0x00007f2c1068d000)
libgthread-2.0.so.0 => /lib64/libgthread-2.0.so.0 (0x00007f2c1048b000)
libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f2c10153000)
libpng15.so.15 => /lib64/libpng15.so.15 (0x00007f2c0ff28000)
libz.so.1 => /lib64/libz.so.1 (0x00007f2c0fd12000)
libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007f2c0fa6b000)
libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00007f2c0f81b000)
libSM.so.6 => /lib64/libSM.so.6 (0x00007f2c0f613000)
libICE.so.6 => /lib64/libICE.so.6 (0x00007f2c0f3f6000)
libXi.so.6 => /lib64/libXi.so.6 (0x00007f2c0f1e6000)
libXrender.so.1 => /lib64/libXrender.so.1 (0x00007f2c0efdc000)
libXrandr.so.2 => /lib64/libXrandr.so.2 (0x00007f2c0edd1000)
libXfixes.so.3 => /lib64/libXfixes.so.3 (0x00007f2c0ebcb000)
libXcursor.so.1 => /lib64/libXcursor.so.1 (0x00007f2c0e9c0000)
libXinerama.so.1 => /lib64/libXinerama.so.1 (0x00007f2c0e7bc000)
libfontconfig.so.1 => /lib64/libfontconfig.so.1 (0x00007f2c0e580000)
libXext.so.6 => /lib64/libXext.so.6 (0x00007f2c0e36e000)
libX11.so.6 => /lib64/libX11.so.6 (0x00007f2c0e02f000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f2c0de2b000)
librt.so.1 => /lib64/librt.so.1 (0x00007f2c0dc23000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2c128b9000)
libffi.so.6 => /lib64/libffi.so.6 (0x00007f2c0da1a000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f2c0d815000)
libexpat.so.1 => /lib64/libexpat.so.1 (0x00007f2c0d5ea000)
libxcb.so.1 => /lib64/libxcb.so.1 (0x00007f2c0d3c8000)
libXau.so.6 => /lib64/libXau.so.6 (0x00007f2c0d1c3000)
I see no missing shared libraries, but also nothing that looks like a JPEG library. QT_PLUGIN_PATH points to /usr/lib64/kde4/plugins, and /usr/lib64/kde4/plugins/imageformats contains these files:
kimg_dds.so
kimg_eps.so
kimg_exr.so
kimg_jp2.so
kimg_pcs.so
kimg_pic.so
kimg_psd.so
kimg_ras.so
kimg_rgb.so
kimg_tga.so
kimg_xcf.so
kimg_xview.so
So no kimg_jpeg.so (if there even is such a thing), and clearly kimg_jp2.so isn't providing JPEG support. So what am I missing?
I am trying to get the opengl version supported on my linux machines.I have a linux machine which have glxinfo output as
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.4, 128 bits)
OpenGL version string: 2.1 Mesa 10.1.3
OpenGL shading language version string: 1.30
I think this means that it supports opengl upto 2.1. Now when I check for Opengl 3.1 version glewIsSupported(GL_VERSION_3_1) and glewIsSupported(GL_VERSION_3_2)it returns true. but it return false for glewIsSupported(GL_VERSION_3_3). glxewIsSupported(GLX_ARB_create_context) also returns true. I also checked
for some extension which were added in opengl 3.1 like
glewIsSupported("GL_ARB_copy_buffer") : returns true
glewIsSupported("GL_ARB_draw_instanced") : returns true
for some extension which were added in opengl 3.2 like
glewIsSupported("GL_ARB_depth_clamp") : returns true
for some extension which were added in opengl 3.3 like
glewIsSupported("GL_ARB_blend_func_extended") : returns false
So does this means means this machine supports opengl 3.2, but then why does glxinfo return it support 2.1. I also tried create oepngl 3.1 forward compatible context, but it fails with following error. So I am assuming that this does not support opengl 3.1.
X Error of failed request: GLXBadFBConfig
Major opcode of failed request: 154 (GLX)
Minor opcode of failed request: 34 ()
Serial number of failed request: 52
Current serial number in output stream: 51
I have one more machine which has
OpenGL vendor string: Advanced Micro Devices, Inc.
OpenGL renderer string: AMD Radeon HD 5450
OpenGL version string: 4.3.12798 Compatibility Profile Context 13.35.1005
OpenGL shading language version string: 4.30
It gives pass for all the extensions. This makes sense I think. But I still dont understand the behavior of first machine.
Basically what I am trying to do is reproduce the condition that first machine does not support opengl 3.1 forward compatibility profile and the second machine does using GLEW as I dont know any other way of doing it. Any help?
Note: I need to check for forward compatible profile or core profile. I asked a similar question earlier but this one is much more informative. So sorry for repeating the question
ldd -> glxinfo
linux-vdso.so.1 => (0x00007fff3b5cc000)
libGL.so.1 => /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1 (0x00007faa836f2000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007faa833bd000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007faa82fff000)
libglapi.so.0 => /usr/lib/x86_64-linux-gnu/libglapi.so.0 (0x00007faa82dd8000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007faa82bc7000)
libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007faa829c4000)
libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007faa827be000)
libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007faa825bc000)
libxcb-glx.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0 (0x00007faa823a5000)
libxcb-dri2.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0 (0x00007faa821a0000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007faa81f82000)
libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007faa81d7d000)
libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 (0x00007faa81b72000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007faa81955000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007faa81751000)
/lib64/ld-linux-x86-64.so.2 (0x00007faa83956000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007faa8154e000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007faa81348000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007faa81140000)
ldd->my program
linux-vdso.so.1 => (0x00007ffef7c7a000)
libmaptype.so => /home/oemtest/mapping/dev/cook_126275//bin/libmaptype.so (0x00007f590b814000)
libpng.so => /home/oemtest/mapping/dev/cook_126275//bin/libpng.so (0x00007f590b5dd000)
libGL.so.1 => /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1 (0x00007f590b379000)
libGLU.so.1 => /usr/lib/x86_64-linux-gnu/libGLU.so.1 (0x00007f590b10b000)
libglut.so.3 => /usr/lib/x86_64-linux-gnu/libglut.so.3 (0x00007f590aec5000)
libGLEW.so.1.5 => /usr/lib/libGLEW.so.1.5 (0x00007f590ac6f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f590a973000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f590a673000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f590a45d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f590a09f000)
zlib.so => /home/oemtest/mapping/dev/cook_126275//bin/zlib.so (0x00007f5909e8a000)
libglapi.so.0 => /usr/lib/x86_64-linux-gnu/libglapi.so.0 (0x00007f5909c63000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f5909a52000)
libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007f590984f000)
libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f5909649000)
libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007f5909447000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f5909112000)
libxcb-glx.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0 (0x00007f5908efb000)
libxcb-dri2.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0 (0x00007f5908cf6000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f5908ad8000)
libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007f59088d3000)
libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 (0x00007f59086c8000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f59084ab000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f59082a7000)
/lib64/ld-linux-x86-64.so.2 (0x00007f590bb77000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f59080a4000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f5907e9e000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f5907c96000)
I have one more machine which have glxinfo output as
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) G45/G43 x86/MMX/SSE2
OpenGL version string: 2.1 Mesa 9.2.1
OpenGL shading language version string: 1.20
Its behavior is similar to the first machine. Also yes, the first machine was a VM. But this new machine is not VM and is physical machine. This is pastebin for full glxinfo log for this new machine http://pastebin.com/hqEPzCPV
glutInit(&argc, argv);
glutInitDisplayMode(/*GLUT_DEPTH |*/ GLUT_DOUBLE | GLUT_RGBA);
glutInitWindowPosition(100,100);
glutInitWindowSize(m_pngWidth, m_pngHeight);
int winID = glutCreateWindow("osm2png");
glewExperimental = GL_TRUE;
GLenum err = glewInit();
if (err != GLEW_OK)
{
return OPENGL_VERSION_UNSUPPORTED;
}
//This shows that it supports opengl version 3.1.
if (glewIsSupported("GL_VERSION_3_1"))
openglDriverType = MT_GLSL_3_1;
else
return OPENGL_VERSION_UNSUPPORTED;
#else
return OPENGL_VERSION_UNSUPPORTED;
It started with httpd not starting on one of my machines:
$ /usr/sbin/httpd -v
/usr/sbin/httpd: error while loading shared libraries: libexpat.so.0: cannot open shared object file: No such file or directory
There are two machines of almost identical configuration. Centos 6.6 32-bit. Both httpd binaries have an identical size and identical md5 sum.
However, the library dependencies are different. I thought those dependencies are embedded into the binary at link time. So how can the dependencies be different?
Below note the broken httpd has two extra dependencies, libexpat.so.0 (not found) and librt.so.1.
Working httpd
# ldd /usr/sbin/httpd
linux-gate.so.1 => (0xb773b000)
libm.so.6 => /lib/libm.so.6 (0xb769c000)
libpcre.so.0 => /lib/libpcre.so.0 (0xb766c000)
libselinux.so.1 => /lib/libselinux.so.1 (0xb764d000)
libaprutil-1.so.0 => /usr/lib/libaprutil-1.so.0 (0xb762a000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0xb75f9000)
libexpat.so.1 => /lib/libexpat.so.1 (0xb75d1000)
libdb-4.7.so => /lib/libdb-4.7.so (0xb745b000)
libapr-1.so.0 => /usr/lib/libapr-1.so.0 (0xb742d000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7412000)
libc.so.6 => /lib/libc.so.6 (0xb727b000)
/lib/ld-linux.so.2 (0x49e18000)
libdl.so.2 => /lib/libdl.so.2 (0xb7275000)
libuuid.so.1 => /lib/libuuid.so.1 (0xb7270000)
libfreebl3.so => /lib/libfreebl3.so (0xb726c000)
Broken httpd
$ ldd /usr/sbin/httpd
linux-gate.so.1 => (0xb7721000)
libm.so.6 => /lib/libm.so.6 (0xb7686000)
libpcre.so.0 => /lib/libpcre.so.0 (0xb7656000)
libselinux.so.1 => /lib/libselinux.so.1 (0xb7637000)
libaprutil-1.so.0 => /usr/lib/libaprutil-1.so.0 (0xb761d000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0xb75ec000)
libexpat.so.1 => /lib/libexpat.so.1 (0xb75c4000)
libdb-4.7.so => /lib/libdb-4.7.so (0xb744e000)
libapr-1.so.0 => /usr/lib/libapr-1.so.0 (0xb7429000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb740e000)
libc.so.6 => /lib/libc.so.6 (0xb7277000)
/lib/ld-linux.so.2 (0x00871000)
libdl.so.2 => /lib/libdl.so.2 (0xb7271000)
libexpat.so.0 => not found
libuuid.so.1 => /lib/libuuid.so.1 (0xb726c000)
librt.so.1 => /lib/librt.so.1 (0xb7263000)
libfreebl3.so => /lib/libfreebl3.so (0xb725f000)
If the binaries are identical, but ldd shows different dependencies, it must have something to do with the earlier dependencies requiring different libraries. Indeed, the output shows that the size of the libraries different between systems. Maybe you could make the system libraries identical by updating one or both systems?
– wallyk
I copied all the referenced libs from a different machine and now it works. – Danny
I was able, easily, to download and install this on Ubuntu with the .deb file. I am currently using Crunchbang and I simply cannot get it to install.
Running it, I get error after error asking for library after library.
After installing all of these and more, I was able to clear up the libQt4* libraries.
apt-get install -y lib32-libpng lib32-libsm lib32-libxi lib32-libxrandr lib32-freetype2 lib32-fontconfig lib32-glib2 lib32-libstdc++5 extra/qtwebkit multilib/lib32-qt
My current error:
root#crunchbang:/usr/local/PacketTracer6/bin# ./PacketTracer6
./PacketTracer6: error while loading shared libraries: libQt3Support.so.4: cannot open shared object file: No such file or directory
I cannot find a package that contains this nor can I find it online. I have already downloaded libraries and LD_PRELOAD libraries to it.
ldd output:
./PacketTracer6: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.15' not found (required by ./PacketTracer6)
linux-gate.so.1 => (0xf76e5000)
libcrypto.so.1.0.0 => /usr/lib/i386-linux-gnu/i686/cmov/libcrypto.so.1.0.0 (0xf7509000)
libQtWebKit.so.4 => /usr/lib/i386-linux-gnu/libQtWebKit.so.4 (0xf5dbe000)
libQtScriptTools.so.4 => /usr/lib/i386-linux-gnu/libQtScriptTools.so.4 (0xf5d06000)
libQtScript.so.4 => /usr/lib/i386-linux-gnu/libQtScript.so.4 (0xf5a7a000)
libQt3Support.so.4 => not found
libQtXml.so.4 => /usr/lib/i386-linux-gnu/libQtXml.so.4 (0xf5a38000)
libQtGui.so.4 => /usr/lib/i386-linux-gnu/libQtGui.so.4 (0xf4f54000)
libQtNetwork.so.4 => /usr/lib/i386-linux-gnu/libQtNetwork.so.4 (0xf4e10000)
libQtCore.so.4 => /usr/lib/i386-linux-gnu/libQtCore.so.4 (0xf4b2a000)
libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xf4b11000)
libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xf4a25000)
libm.so.6 => /lib/i386-linux-gnu/i686/cmov/libm.so.6 (0xf49ff000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf49e1000)
libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xf487d000)
libdl.so.2 => /lib/i386-linux-gnu/i686/cmov/libdl.so.2 (0xf4879000)
libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xf4860000)
libsqlite3.so.0 => /usr/lib/i386-linux-gnu/libsqlite3.so.0 (0xf47b0000)
libXrender.so.1 => /usr/lib/i386-linux-gnu/libXrender.so.1 (0xf47a5000)
libgstapp-0.10.so.0 => /usr/lib/i386-linux-gnu/libgstapp-0.10.so.0 (0xf4797000)
libgstinterfaces-0.10.so.0 => /usr/lib/i386-linux-gnu/libgstinterfaces-0.10.so.0 (0xf4785000)
libgstpbutils-0.10.so.0 => /usr/lib/i386-linux-gnu/libgstpbutils-0.10.so.0 (0xf4761000)
libgstvideo-0.10.so.0 => /usr/lib/i386-linux-gnu/libgstvideo-0.10.so.0 (0xf4743000)
libgstbase-0.10.so.0 => /usr/lib/i386-linux-gnu/libgstbase-0.10.so.0 (0xf46df000)
libgstreamer-0.10.so.0 => /usr/lib/i386-linux-gnu/libgstreamer-0.10.so.0 (0xf45f5000)
libgobject-2.0.so.0 => /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 (0xf45a3000)
libglib-2.0.so.0 => /lib/i386-linux-gnu/libglib-2.0.so.0 (0xf44a6000)
libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xf436e000)
libfontconfig.so.1 => /usr/lib/i386-linux-gnu/libfontconfig.so.1 (0xf4337000)
libaudio.so.2 => /usr/lib/i386-linux-gnu/libaudio.so.2 (0xf431d000)
libpng12.so.0 => /lib/i386-linux-gnu/libpng12.so.0 (0xf42f3000)
libfreetype.so.6 => /usr/lib/i386-linux-gnu/libfreetype.so.6 (0xf4257000)
libSM.so.6 => /usr/lib/i386-linux-gnu/libSM.so.6 (0xf424f000)
libICE.so.6 => /usr/lib/i386-linux-gnu/libICE.so.6 (0xf4235000)
libXext.so.6 => /usr/lib/i386-linux-gnu/libXext.so.6 (0xf4223000)
librt.so.1 => /lib/i386-linux-gnu/i686/cmov/librt.so.1 (0xf421a000)
/lib/ld-linux.so.2 (0xf76e6000)
liborc-0.4.so.0 => /usr/lib/i386-linux-gnu/liborc-0.4.so.0 (0xf4189000)
libgmodule-2.0.so.0 => /usr/lib/i386-linux-gnu/libgmodule-2.0.so.0 (0xf4183000)
libxml2.so.2 => /usr/lib/i386-linux-gnu/libxml2.so.2 (0xf402f000)
libgthread-2.0.so.0 => /usr/lib/i386-linux-gnu/libgthread-2.0.so.0 (0xf402c000)
libffi.so.5 => /usr/lib/i386-linux-gnu/libffi.so.5 (0xf4023000)
libpcre.so.3 => /lib/i386-linux-gnu/libpcre.so.3 (0xf3fe5000)
libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xf3fc1000)
libexpat.so.1 => /lib/i386-linux-gnu/libexpat.so.1 (0xf3f99000)
libXt.so.6 => /usr/lib/i386-linux-gnu/libXt.so.6 (0xf3f3c000)
libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xf3f39000)
libuuid.so.1 => /lib/i386-linux-gnu/libuuid.so.1 (0xf3f33000)
liblzma.so.5 => /lib/i386-linux-gnu/liblzma.so.5 (0xf3f0b000)
libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xf3f05000)
Running 'file' on PacketTracer6 ($ file PacketTracer6 )
shows the executable to be 32-bit.
It won't run at all on amd64 OS's without the supporting
32-bit libraries installed.
That is you need to set up your system as a multi-architecture
one.
On debian it's # dpkg --add-architecture i386
I haven't completed this, yet, so I don't know how many of
the necessary libs go in by default, and how many would have
to be installed slowly and by hand.
If someone else beats me to it, feel free to add to this.
You need to compile/install libQt3 because PacketTracer6 requires libQt3 library as ldd shows
libQt3Support.so.4 => not found
you need to install libqt4-qt3support from synaptic package manager
The packed in libraries depend on GCLIB 2.15 but wheezy comes with 2.13.
This helped for me:
apt-get install libqt4-qt3support:i386
apt-get install libqt4-scripttools:i386
mv /opt/pt/lib /opt/pt/lib.bak
mkdir /opt/pt/lib
ln -s /usr/lib/i386-linux-gnu/libQt* /opt/pt/lib