Created attachment 351556 [details] gdal build.log I am trying the new mesa implementation for opencl. checking for -lGL... yes checking for -lGL... libGL.so.1 checking for gluLookAt in -lGLU... libGL.so.1 checking for gluLookAt in -lGLU... yes checking for -lOSMesa... yes checking for -lOSMesa... not found checking for -lOSMesa... libOSMesa.so.8 checking for clGetPlatformInfo in -lOpenCL... no configure: error: OpenCL development files not found, OpenCL won't be supported. This is an error since --with-opencl was requested. not found configure: error: libOSMesa development files not found (or too old), OpenGL rendering in bitmaps won't be supported. This is an error since --with-osmesa was requested. app-admin/eselect-opencl-1.1.0-r1 was built with the following: USE="(multilib)" ABI_X86="64" virtual/opencl-0-r3 was built with the following: USE="" VIDEO_CARDS="-fglrx -nvidia" CHOST="" media-libs/mesa-9.2_pre20130619 was built with the following: USE="classic egl gallium llvm nptl opencl osmesa r600-llvm-compiler shared-glapi vdpau xa xorg xvmc -bindist -debug -gbm -gles1 -gles2 -openvg -pax_kernel -pic (-selinux) -wayland" PYTHON_SINGLE_TARGET="python2_7 -python2_6" PYTHON_TARGETS="python2_7 -python2_6" VIDEO_CARDS="r600 radeon radeonsi -freedreno -i915 -i965 -ilo -intel -nouveau -r100 -r200 -r300 -vmware" sys-devel/clang-3.3 was built with the following: USE="static-analyzer -debug -multitarget -python -test" PYTHON_TARGETS="python2_7 -pypy1_9 -pypy2_0 -python2_6" dev-libs/libclc-0.0.1_pre20130524 was built with the following: USE=""
With gdal-1.10.0-r1 And vlc I have another bug related to opencl. https://bugs.gentoo.org/show_bug.cgi?id=475058 I mixed that up with this bug at first so happened the title change. I found, there is a warning before the undefined messages: /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/../../../../x86_64-pc-linux-gnu/bin/ld: warning: libLLVM-3.3.so, needed by /usr/lib/libOpenCL.so, not found (try using -rpath or -rpath-link) /usr/lib/libOpenCL.so: undefined reference to `llvm::ConstantExpr::get(unsigned int, llvm::Constant*, llvm::Constant*, unsigned int)' jlgentoo ~ # equery b libLLVM-3.3.so * Searching for libLLVM-3.3.so ... sys-devel/llvm-3.3 (/usr/lib64/llvm/libLLVM-3.3.so) jlgentoo ~ # ls -l /usr/lib64/llvm/libLLVM-3.3.so -rwxr-xr-x 1 root root 16789648 21. Jun 12:05 /usr/lib64/llvm/libLLVM-3.3.so jlgentoo ~ # equery b /usr/lib/libOpenCL.so * Searching for /usr/lib/libOpenCL.so ... media-libs/mesa-9.2_pre20130619 (/usr/lib64/OpenCL/vendors/mesa/libOpenCL.so.1.0.0) jlgentoo ~ # ls -l /usr/lib64/OpenCL/vendors/mesa/ insgesamt 14728 drwxr-xr-x 3 root root 4096 21. Jun 13:31 include drwxr-xr-x 2 root root 4096 21. Jun 13:31 lib lrwxrwxrwx 1 root root 18 26. Jun 14:24 libOpenCL.so -> libOpenCL.so.1.0.0 lrwxrwxrwx 1 root root 18 26. Jun 14:24 libOpenCL.so.1 -> libOpenCL.so.1.0.0 -rwxr-xr-x 1 root root 15068616 26. Jun 14:24 libOpenCL.so.1.0.0
*** Bug 475058 has been marked as a duplicate of this bug. ***
since googleearth defaults to bundled-libs "on",gdal was not needed anymore on my system. VirtualBox told me that 3d is not available on host. tried packmanarena: screen_switch_resolution: couldn't set mode (800x600x32 fullscreen) vdpauinfo display: :0 screen: 0 Failed to open VDPAU backend libvdpau_r600.so: cannot open shared object file: No such file or directory Error creating VDPAU device: 1 jlgentoo ~ # equery b libvdpau_r600.so * Searching for libvdpau_r600.so ... app-emulation/emul-linux-x86-opengl-20130224 (/usr/lib32/vdpau/libvdpau_r600.so -> libvdpau_r600.so.1) media-libs/mesa-9.2_pre20130619 (/usr/lib64/vdpau/libvdpau_r600.so -> libvdpau_r600.so.1.0.0) jlgentoo ~ # ls -lt /usr/lib64/vdpau/libvdpau* lrwxrwxrwx 1 root root 22 29. Jun 14:31 /usr/lib64/vdpau/libvdpau_r600.so.1 -> libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 29. Jun 14:31 /usr/lib64/vdpau/libvdpau_r600.so -> libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 26 29. Jun 14:31 /usr/lib64/vdpau/libvdpau_softpipe.so -> libvdpau_softpipe.so.1.0.0 lrwxrwxrwx 1 root root 26 29. Jun 14:31 /usr/lib64/vdpau/libvdpau_radeonsi.so.1 -> libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 26 29. Jun 14:31 /usr/lib64/vdpau/libvdpau_radeonsi.so -> libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 26 29. Jun 14:31 /usr/lib64/vdpau/libvdpau_softpipe.so.1 -> libvdpau_softpipe.so.1.0.0 -rwxr-xr-x 1 root root 2219088 29. Jun 14:31 /usr/lib64/vdpau/libvdpau_softpipe.so.1.0.0 -rwxr-xr-x 1 root root 2145240 29. Jun 14:31 /usr/lib64/vdpau/libvdpau_radeonsi.so.1.0.0 -rwxr-xr-x 1 root root 2993752 29. Jun 14:31 /usr/lib64/vdpau/libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 23 16. Mai 00:45 /usr/lib64/vdpau/libvdpau_trace.so.1 -> libvdpau_trace.so.1.0.0 lrwxrwxrwx 1 root root 23 16. Mai 00:45 /usr/lib64/vdpau/libvdpau_trace.so -> libvdpau_trace.so.1.0.0 -rwxr-xr-x 1 root root 51072 16. Mai 00:45 /usr/lib64/vdpau/libvdpau_trace.so.1.0.0 jlgentoo ~ # jlgentoo ~ # ls -lt /usr/lib32/vdpau/libvdpau* lrwxrwxrwx 1 root root 23 26. Feb 18:01 /usr/lib32/vdpau/libvdpau_trace.so.1 -> libvdpau_trace.so.1.0.0 lrwxrwxrwx 1 root root 23 26. Feb 18:01 /usr/lib32/vdpau/libvdpau_trace.so -> libvdpau_trace.so.1.0.0 lrwxrwxrwx 1 root root 20 26. Feb 18:00 /usr/lib32/vdpau/libvdpau_r600.so.1 -> libvdpau_r600.so.1.0 lrwxrwxrwx 1 root root 23 26. Feb 18:00 /usr/lib32/vdpau/libvdpau_nouveau.so.1 -> libvdpau_nouveau.so.1.0 lrwxrwxrwx 1 root root 18 26. Feb 18:00 /usr/lib32/vdpau/libvdpau_r600.so -> libvdpau_r600.so.1 lrwxrwxrwx 1 root root 20 26. Feb 18:00 /usr/lib32/vdpau/libvdpau_r300.so.1 -> libvdpau_r300.so.1.0 lrwxrwxrwx 1 root root 18 26. Feb 18:00 /usr/lib32/vdpau/libvdpau_r300.so -> libvdpau_r300.so.1 lrwxrwxrwx 1 root root 22 26. Feb 18:00 /usr/lib32/vdpau/libvdpau_softpipe.so -> libvdpau_softpipe.so.1 lrwxrwxrwx 1 root root 21 26. Feb 18:00 /usr/lib32/vdpau/libvdpau_nouveau.so -> libvdpau_nouveau.so.1 lrwxrwxrwx 1 root root 24 26. Feb 18:00 /usr/lib32/vdpau/libvdpau_softpipe.so.1 -> libvdpau_softpipe.so.1.0 -rwxr-xr-x 1 root root 13870416 24. Feb 23:46 /usr/lib32/vdpau/libvdpau_nouveau.so.1.0 -rwxr-xr-x 1 root root 13345872 24. Feb 23:46 /usr/lib32/vdpau/libvdpau_r300.so.1.0 -rwxr-xr-x 1 root root 1132548 24. Feb 23:46 /usr/lib32/vdpau/libvdpau_r600.so.1.0 -rwxr-xr-x 1 root root 13103120 24. Feb 23:46 /usr/lib32/vdpau/libvdpau_softpipe.so.1.0 -rwxr-xr-x 1 root root 54444 24. Feb 20:00 /usr/lib32/vdpau/libvdpau_trace.so.1.0.0 jlgentoo ~ # Should mesa install files in /usr/lib32/vdpau on a 64bit system? media-libs/mesa-9.2_pre20130619 was built with the following: USE="classic egl gallium llvm nptl opencl osmesa r600-llvm-compiler vdpau xa xorg xvmc -bindist -debug -gbm -gles1 -gles2 -openvg -pax_kernel -pic (-selinux) -wayland" PYTHON_SINGLE_TARGET="python2_7 -python2_6" PYTHON_TARGETS="python2_7 -python2_6" VIDEO_CARDS="r600 radeon radeonsi -freedreno -i915 -i965 -ilo -intel -nouveau -r100 -r200 -r300 -vmware"
x11-libs/libvdpau-0.6 was built with the following: USE="dri -doc" ABI_X86="64 -32 -x32" jlgentoo ~ # emerge -va1 libvdpau These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] x11-libs/libvdpau-0.6 USE="dri -doc" ABI_X86="(64) -32 (-x32)" 0 kB should this set to 32 and 64 ?
I think gdal and wine are not guilty. But the whole mesa (llvm,vdpau) is broken with these (USE-)settings because of bad linking or missing files. wine and gdal fail to configure because they perhaps try to use some files from /usr/lib32 that belong to app-emulation/emul-linux-x86-opengl-20130224 joerg@j.lgentoo ~ $ cat /var/log/Xorg.0.log|grep "(EE)" (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 17.478] (EE) AIGLX error: dlopen of /usr/lib64/dri/r600_dri.so failed (libLLVM-3.3.so: cannot open shared object file: No such file or directory) [ 17.478] (EE) AIGLX: reverting to software rendering [ 17.528] (EE) AIGLX error: dlopen of /usr/lib64/dri/swrast_dri.so failed (libLLVM-3.3.so: cannot open shared object file: No such file or directory) [ 17.528] (EE) GLX: could not load software renderer joerg@jlgentoo ~ $ ls -lt /usr/lib64/dri/ insgesamt 0 lrwxrwxrwx 1 root root 19 29. Jun 14:31 r200_dri.so -> ../mesa/r200_dri.so lrwxrwxrwx 1 root root 20 29. Jun 14:31 r600g_dri.so -> ../mesa/r600g_dri.so lrwxrwxrwx 1 root root 22 29. Jun 14:31 swrastg_dri.so -> ../mesa/swrastg_dri.so lrwxrwxrwx 1 root root 21 29. Jun 14:31 radeon_dri.so -> ../mesa/radeon_dri.so lrwxrwxrwx 1 root root 23 29. Jun 14:31 radeonsi_dri.so -> ../mesa/radeonsi_dri.so lrwxrwxrwx 1 root root 20 15. Okt 2012 r600_dri.so -> ../mesa/r600g_dri.so lrwxrwxrwx 1 root root 22 24. Jul 2011 swrast_dri.so -> ../mesa/swrastg_dri.so joerg@jlgentoo ~ $ joerg@jlgentoo ~ $ ls -l /usr/lib64/mesa/ insgesamt 18492 -rwxr-xr-x 1 root root 330112 29. Jun 14:31 r200_dri.so -rwxr-xr-x 1 root root 6624424 29. Jun 14:31 r600g_dri.so -rwxr-xr-x 1 root root 297120 29. Jun 14:31 radeon_dri.so -rwxr-xr-x 1 root root 5755528 29. Jun 14:31 radeonsi_dri.so -rwxr-xr-x 1 root root 27016 29. Jun 14:31 swrast_dri.so -rwxr-xr-x 1 root root 5886704 29. Jun 14:31 swrastg_dri.so @Jeroen Roovers: Could we please reassign the bug? Do we need another title? I don't know how to go on with this. This should work somehow. Another way for me could be to go back and disable the whole opencl thing.
If I disable the opencl USE-flag and let the packages with newuse reemerge then all broken programms work again. So the bug only comes when opencl with mesa vdpau and llvm is enabled.
@ Bug wranglers: Could you please reassign the bug to the MESA maintainer?
same as bug 474450
I looked thru the 2 other similiar bugs and with the hint to add missing pathes for ld in /etc/ld.so.conf.d/ by creating a file there for example 05llvm_jl.conf . I decided to give opencl a new try. I added following entries: /usr/$(get_libdir)/llvm /usr/lib64/vdpau/ /usr/lib64/llvm/ After this I had to run ldconfig. The first entry did not help. now vdpau,packmanarena, emerge gdal-1.10.0-r1 with opencl works. but emerge wine has still a opencl problem: ........ configure:9606: checking for clGetPlatformInfo in -lOpenCL configure:9631: x86_64-pc-linux-gnu-gcc -m32 -o conftest -march=native -O2 -pipe -Wl,-O1 -Wl,--as-needed conftest.c -lOpenCL >&5 /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/../../../libOpenCL.so when searching for -lOpenCL /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libOpenCL.so when searching for -lOpenCL /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lOpenCL collect2: error: ld returned 1 exit status configure:9631: $? = 1 ..... I found something here: https://github.com/vikasnkumar/wisecracker/issues/1 have I to set OPENCL_ROOT ? jlgentoo ~ # ls -l /usr/lib64/OpenCL/vendors/mesa/ insgesamt 14724 drwxr-xr-x 3 root root 4096 10. Jul 23:22 include drwxr-xr-x 2 root root 4096 10. Jul 23:22 lib lrwxrwxrwx 1 root root 18 10. Jul 23:22 libOpenCL.so -> libOpenCL.so.1.0.0 lrwxrwxrwx 1 root root 18 10. Jul 23:22 libOpenCL.so.1 -> libOpenCL.so.1.0.0 -rwxr-xr-x 1 root root 15068616 10. Jul 23:22 libOpenCL.so.1.0.0 jlgentoo ~ # A added /usr/lib64/OpenCL/vendors/mesa/ /usr/lib64/OpenCL/ to my 05llvm_jl.conf file bat did not help. .... #define SONAME_LIBGL "libGL.so.1" | #define SONAME_LIBOSMESA "libOSMesa.so.8" | /* end confdefs.h. */ | | /* Override any GCC internal prototype to avoid an error. | Use char because int might match the return type of a GCC | builtin and then its argument prototype would still apply. */ | #ifdef __cplusplus | extern "C" | #endif | char clGetPlatformInfo (); | int | main () | { | return clGetPlatformInfo (); | ; | return 0; | } configure:9640: result: no configure:9652: error: OpenCL development files not found, OpenCL won't be supported. This is an error since --with-opencl was requested. ....................
I still have the problem with wine and OpenCl. As far as I found out is that the configure item for OpenCL searches in the wrong directory for a file. checking for -lOSMesa... libOSMesa.so.8 checking for clGetPlatformInfo in -lOpenCL... no configure: error: OpenCL development files not found, OpenCL won't be supported. This is an error since --with-opencl was requested. /var/tmp/portage/app-emulation/wine-9999/work/wine-9999-x86/config.log: configure:6073: checking OpenCL/opencl.h usability configure:6073: x86_64-pc-linux-gnu-gcc -m32 -c -march=native -O2 -pipe conftest.c >&5 conftest.c:56:27: fatal error: OpenCL/opencl.h: No such file or directory #include <OpenCL/opencl.h> ^ compilation terminated. configure:6073: $? = 1
*** Bug 497696 has been marked as a duplicate of this bug. ***
Still have this issue.
Please test a newer version of Mesa. I'm not sure what the status of this report is.
(In reply to Matt Turner from comment #14) > Please test a newer version of Mesa. I'm not sure what the status of this > report is. Still happens with current mesa from git. So I think all previous versions are affected.
[I] media-libs/mesa Installed versions: 11.0.6^d(11:55:05 PM 07/18/2016)(classic d3d9 dri3 egl gallium gbm gles2 llvm nptl opencl udev vaapi vdpau -bindist -debug -gles1 -openmax -osmesa -pax_kernel -pic -selinux -wayland -xa -xvmc ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="32 64 -x32" KERNEL="-FreeBSD" VIDEO_CARDS="i915 i965 intel -freedreno -ilo -nouveau -r100 -r200 -r300 -r600 -radeon -radeonsi -vmware") [U] app-emulation/wine Installed versions: 1.8.3^t(09:42:23 PM 08/08/2016)(X alsa cups fontconfig gecko gstreamer jpeg lcms ldap mono mp3 ncurses nls odbc openal opencl opengl pcap perl pipelight png realtime run-exes s3tc samba ssl staging threads truetype udisks v4l vaapi xcomposite xinerama xml -capi -custom-cflags -dos -gphoto2 -gsm -netapi -osmesa -oss -prelink -pulseaudio -scanner -selinux -test ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="32 64 -x32" ELIBC="glibc" KERNEL="-FreeBSD" LINGUAS="en en_US -ar -bg -ca -cs -da -de -el -eo -es -fa -fi -fr -he -hi -hr -hu -it -ja -ko -lt -ml -nb_NO -nl -or -pa -pl -pt_BR -pt_PT -rm -ro -ru -sk -sl -sr_RS@cyrillic -sr_RS@latin -sv -te -th -tr -uk -wa -zh_CN -zh_TW") I have wine and mesa with opencl. Are you still able to reproduce with us? or is this just a gdal issue?
(In reply to NP-Hardass from comment #16) > Are you still able to reproduce with us? or is this just a gdal issue? I'd err on saying either treat this like a fresh report, full logs/steps to reproduce, current description of problem, or file a new bug instead. If you file a new bug, add this one to the see also field. This bug is kind of convoluted in purpose/content/scope at this point, IMO. (X packagers, feel free to say otherwise, but from wine's end, I'm at a loss of how to proceed from here)
I think I can set this to fixed because of a lot of changes/version bumps to that packages in Gentoo or upstream. I did not have related issues the last years.
