Following this post, where I have used these instructions to install NVIDIA's OpenCL SDK. The clinfo tool detects a 1.2 OpenCL version correctly. However, The below CMakeLists.txt file:
cmake_minimum_required(VERSION 3.1)
project(OpenCL_Example)
find_package(OpenCL REQUIRED)
include_directories(${OpenCL_INCLUDE_DIRS})
link_directories(${OpenCL_LIBRARY})
add_executable(main main.c)
target_include_directories(main PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})
target_link_libraries(main ${OpenCL_LIBRARY})
copied from here, detects the wrong version of OpenCL 1.1 :
-- Looking for CL_VERSION_1_1 - found
-- Found OpenCL: C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v3.2/lib/Win32/OpenCL.lib (found version "1.1")
I would appreciate it if you could help me know what is the problem and how I can resolve it.
P.S.1. you may use the below dummy main.c C code just for testing
#include <CL/cl.h>
#include <stdio.h>
int main() {
printf("Hello, World! \n");
return 0;
}
P.S.2. Following this Tweet, I ran the cmake .. --debug-find command and got this log. But still not sure what is the problem.
P.S.3. Following this Tweet, it turns out that I had installed a very outdated CUDA toolkit. Uninstalling that, now I get
-- Found OpenCL: C:/Program Files (x86)/IntelSWTools/system_studio_2020/OpenCL/sdk/lib/x86/OpenCL.lib (found version "2.2")
which is Intel's SDK. It was basically the second result on Google search " NVIDIA OpenCL SDK download", firstly being completely confusing. So I had to uninstall it and install the latest version from here. NVIDIA could at least mention that one has to install CUDA toolkit to get the OpenCL SDK!
NVidia Cuda v3.2 was released according to this on Nov 2010 and OpenCL 1.2 spec was released one year later on November 15, 2011. So I suspect cmake is detecting OpenCL 1.1 correctly.
If you have another SDK installed and you want cmake to detect OpenCL 1.2 despite having another SDKs supporting older version you need to specify that information in cmake. Otherwise it will find the first OpenCL on the search path and stop. So it should be specified find_package(OpenCL 1.2 REQUIRED) or as #squareskittles pointed find_package(OpenCL 1.2 EXACT REQUIRED) if you want exact version.
However you may need to add other SDKs paths to PATH or specify them in cmake so that it has a chance to examine other OpenCL versions. If you have a look at find cmake macros content they contain some typical search paths specified and if you have SDK installed in other not standard path you have to tell that cmake yourself. That is especially the case on Windows where you don't have standard more specific install paths for includes or libraries like for example on Linux. On Windows there is really Program Files but that is too generic and cmake would have to search through it recursively and I'm not sure if that is even supported.
I suspect you may have nvidia cuda 3.2 toolkit path added to PATH only or you specified that path in cmake only. So here would the problem lie. Adding other SDKs paths may resolve the issue.
Also I think clinfo checks runtime OpenCL installations meaning it can be any vendor OpenCL.dll which supports OpenCL 1.2 on your NVidia GPU and cmake checks in SDK's header which OpenCL version your installed SDK supports. So here can be the discrepancy. In this case you may need to install newer cuda toolkit.
Related
I have some code which includes the headers GL/glx.h , GL/gl.h and GL/glu.h . I do not even know what these are, and Google is not a lot of help because there is so much noise in the search results. So (optionally) what are they, but more importantly, how do I install them on a Mac (Mac OS 10.15.4). I have installed other stuff using homebrew so that would be my preference.
EDIT: By renaming the headers to OpenGL/glx.h etc, I can now find gl.h abd glu.h but not glx.h.
This answer openGL glx.h missing form xcode 4 mac lion says "If you install XQuartz you get X11 which has glx.h" but this is not correct, at least not for me. I have installed xquartz using brew, but still cannot find glx.h.
Another site suggested installing Xcode, which I did, but that does not contain glx.h either.
Installing xquartz fixed it. OpenGL (at least the versions I found) is insufficient because it does not include glx.h. The page xquartz.org says, "The XQuartz project is an open-source effort to develop a version of the X.Org X Window System that runs on OS X. Together with supporting libraries and applications, it forms the X11.app that Apple shipped with OS X versions 10.5 through 10.7."
So I downloaded and installed xquartz, and then compiled with -I/opt/X11/include instead of -I/usr/X11R6/include, and linked with -L/opt/X11/lib instead of -L/usr/X11R6/lib; as suggested at fatal error 'GL/glx.h' file not found on mac after Xquartz is installed ; and it all worked.
I have been using gcc version 5.3.0. It says that it comes with openmp support. But every time when I compile a program using either gcc [by terminal] or via xCode 7, I get same error, "file omp.h not found". I have searched too much on this issue and tried almost everything I found.
First I tried to locate omp.h on my mac. I found some files; then in header file, I used that specific location of omp.h but no help [it gave me linker error].
I installed gcc version 6.0 (pre-release) but no help. I tried changing C_INCLUDE_PATH [which is now, and previously set to none] but that didn't helped me as well.
I reinstalled clang-omp but no help.
I am using llvm compiler version 7.0. Although i have installed clang-omp, there is no omp.h in my /usr/include/*
I changed the compiler and now I am able to run it. [It was issue of clang, which I couldn't solve].
I am a student and Intel is giving Intel Parallel Studio 1 year licence for free to students.
So I downloaded, and installed it.
In xCode, under build settings, I set my compiler to 'Intel C/C++ compiler' and in parallalization, I turned it to 'yes'. That was it. Then it compiled successfully. But, note that you won't be using header file 'omp.h' anymore.
By the way, I am still looking for answers, just to know what I was doing wrong.
You can install 'clang-omp' or 'gcc' (corresponds to GCC 5.3 right now) packages via Homebrew, both of which support OpenMP.
The built in GCC is based upon GCC 4.2.1 abs uses LLVM back end via Dragonegg, which is why it doesn't support OpenMP.
As noted already, Intel compilers support OpenMP on Mac.
I don't use Xcode editor so I don't know how to use any of these from there, but all will work from terminal just as they do on Linux.
the compiler on the mac is clang (based on llvm 3.5) which does not support openmp.
you can try install llvm/clang/openmp from source or using prebuild binaries, but I must admit it does not work as advertised for me…
edit unless you use the -fopenmp=libomp flag.
I am trying to compile native linux c files on windows using GNU GCC compilers. For the installation purpose, I have followed the steps mentioned by Faheem in the following link :
Using GCC(minGW) as Matlab's MEX compiler
the example given there compiled successfully. but when i am trying to compile a file using thread functions, the following error is being thrown:
fatal error: pthread.h: No such file or directory
#include
^
compilation terminated.
I have installed all the components from MinGW installer related to GNU C compiler bu still the error persists. Can any one suggest a way to solve this problem. Thanks in advance.
According to the TDM-GCC "Quircks" page, TDM-GCC includes a pthreads emulation layer for Microsoft Windows systems, called "winpthreads", and a recent toolchain you should have x86_64-w64-mingw32\include\pthread.h in the TDM install path. So, I don't know what is wrong with Faheem's instructions, but you should have no trouble including pthread.h if MATLAB is configured correctly.
What is not stated on the TDM Quircks page is that TDM uses Winpthreads from the MinGW-w64 project. From the current README installed with TDM:
"Winpthreads" is one of the libraries distributed by the MinGW-w64 project, and
it allows GCC to be compiled with full pthreads compatibility, which is
necessary to enable std::thread and other threading related functions in the
C++ runtime.
As it states, Pthreads is part of the MinGW-w64 project and you can also get it with MinGW-w64 if you pick a pthreads enabled toolchain. For MinGW-w64, I do the following to set it up (see here for more details):
Grab the latest revision for w64 from Sourceforge (or use the installer to choose the toolchain you want, picking a pthread version).
Extract it so that you have a path to the compiler like C:\mingw-w64\x86_64-4.9.2-release-posix-seh-rt_v3-rev1\bin\x86_64-w64-mingw32-g++.exe. There is no need for MSYS, cygwin, or any other environment if you plan on compiling in MATLAB with mex.
Set it up with a custom mexopts.bat or using the new xml configuration system. On my GitHub repo, I have C++ configurations for MinGW-w64 in both file types: mingw_mexopts.bat and mex_C++_mingw-w64.xml. For example, using the xml file to set up C++ MEX file compilation:
mex -setup:C:\Users\Jon\Documents\MATLAB\mex_C++_mingw-w64.xml C++
If needed, set up the C compiler in a similar manner by modifying the config files.
I posted a more detailed version of the above instructions in my answer to the canonical question on the MinGW-with-MATLAB topic.
I am newbie in cygwin. However, I have used mingw so far, but it is not supporting fork(), so I need to switch to cygwin.
Does cygwin support opencv and how (reference)?
I'm the maintainer of http://hvrl.ics.keio.ac.jp/kimura/opencv/. I fixed the bug in loading jpeg files. Please check my new patch.
I just installed opencv with cygwin, all recent distributions. I found ** THIS LINK ** very helpful. You're suppose to install first ffmpeg, then to patch opencv 2.4.2 distribution (!!) and, eventually, to install opencv.
To make it work with pkg-config I had to modify ${OPENCV_ROOTDIR}\lib\pkgconfig and to filter windows path syntax to unix path syntax. pkg-config is not mandatory but it simplifies application development (when correctly installed).
After some effort all this works; but if I can open pgn image files I can't open jpeg image files... Still investigating...
Claude
This is kind of an ugly one, but I am stuck so here it goes:
I am writing a dynamic library (henceforth 'mylib.dylib') that uses opencv (highgui and other parts) and is ultimately loaded by ffmpeg (libavfilter). The library compiles just fine. But when I try to dlopen() the dylib from within ffmpeg, I get the following error:
mylib.dylib: dlopen(mylib.dylib, 2): Library not loaded: /usr/local/lib/libpng15.15.dylib
Referenced from: /usr/local/lib/libopencv_highgui.2.3.dylib
Reason: Incompatible library version: libopencv_highgui.2.3.dylib requires version 17.0.0 or later, but libpng15.15.dylib provides version 16.0.0
However, when I run otool -L /usr/local/lib/libpng15.15.dylib I get the following:
/usr/local/lib/libpng15.15.dylib:
/usr/local/lib/libpng15.15.dylib (compatibility version 20.0.0, current version 20.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.0.0)
Last time I checked, 20.0.0 is later than 17.0.0, which is what highgui said it requires.
I thought maybe it was an architecture problem (I am on a Mac running Lion, so I've encountered a lot of problems with i386/x86_64), but running 'file' on all of the libraries revealed that everything (highgui, libpng, mylib) is Mach-O 64-bit dynamically linked shared library x86_64
I thought perhaps there was some other version of libpng hiding on my system somewhere, but the dlopen error specifically points to /usr/local/lib/libpng15.15.dylib
There is obviously something that I am missing here -- admittedly I am no expert on how these dynamic libraries link. So if I forgot to include some pertinent info, please excuse me.
UPDATE
I forgot to mention -- the lib works fine when I run ffmpeg through XCode (no dlopen error) which leads me to believe that it might have something to do with a environment variable that XCode is setting that I am not.
Thanks!
SOLUTION
1. Don't be dumb
I was using MAMP and since I was calling ffmpeg through a php script, it was using its own set of dylibs, which (surprise surprise) included libpng 16.0.0
I had something similar recently after I uninstalled all my MacPorts and installed updated versions. The problem was the version of libpng (1.2 vs 1.4 vs 1.5), not just the compatibility version. I had built OpenCV against libpng 1.4 (which is libpng14). I thought I could just use install_name_tool to make it look at libpng 1.5 (libpng15) instead but that didn't work. I ended up rebuilding OpenCV against the current versions of the library. That worked fine (after I remembered sudo cmake install).
(Some version numbers above might be incorrect but the gist is accurate.)
So either you don't have the version of libpng you originally had when you built OpenCV or it built against a libpng other than the one in /usr/local/lib (like maybe the one in /opt/local/lib). If that's the case you'll need to make sure you're building against the version you want to use. How to do that depends on your build method (MacPorts or cmake). I use cmake for OpenCV and MacPorts for other libraries which is why the two got out of sync on my system.
Just for those who need the code:
cd /Applications/MAMP/Library/lib
mv libpng15.15.dylib libpng15.15.dylib_old
ln -s /usr/X11/lib/libpng15.15.dylib .