Building OpenCV with CUDA support Error on transpose.cu - opencv

Recently I am trying to build OpenCV with CUDA support, and I met problem while building the module cudaarithm.
OpenCV source: git cloned from : http://github.com/Itseez/opencv.git
OpenCV branch: master branch
OpenCV commit:
`commit 5466e321b8c8f97536002a357e5b7ff49a5d2bf9, on Tue Feb 10 12:17:11 2015 +0000`
CUDA version: CUDA 6.5
Hardware: MacBook Pro (13-inch, Mid 2010)
GPU: NVIDIA GeForce 320M 256 MB
OS Version: OS X Yosemite
Steps I used:
1. cd in OpenCVSource, then mkdir myrelease, and cd myrelease
2. cmake -DPLANTUML_JAR=/usr/local/Cellar/plantuml/8002 -D BUILD_DOCS=1 -DPYTHON2_LIBRARY=/usr/local/Cellar/python/2.7.8_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config/libpython2.7.dylib -DPYTHON2_INCLUDE_DIR=/usr/local/Cellar/python/2.7.8_2/Frameworks/Python.framework/Versions/2.7/include/python2.7 -DPYTHON3_LIBRARY=/usr/local/Cellar/python3/3.4.2_1/Frameworks/Python.framework/Versions/3.4/lib/libpython3.4m.dylib -DPYTHON3_INCLUDE_DIR=/usr/local/Cellar/python3/3.4.2_1/Frameworks/Python.framework/Versions/3.4/include/python3.4m -D CMAKE_BUILD_TYPE=RELEASE -DCMAKE_INSTALL_PREFIX=/usr/local -Wno-dev -DNVCC_FLAGS_EXTRA="-Xcompiler -stdlib=libstdc++; -Xlinker -stdlib=libstdc++" -DOPENCV_EXTRA_CXX_FLAGS=" -stdlib=libstdc++" -DOPENCV_EXTRA_EXE_LINKER_FLAGS="-stdlib=libstdc++" ..
3. make VERBOSE=1
Expect Result: Building success without error
Actual Result: when building OpenCVSource/modules/cudaarithm/src/cuda/transpose.cu, error happend like below:
/Users/Hawk/Documents/study/DIP/OpenCV/OpenCVSource/modules/cudaarithm/src/cuda/transpose.cu(61): *error: identifier "getInputMat" is undefined*
/Users/Hawk/Documents/study/DIP/OpenCV/OpenCVSource/modules/cudaarithm/src/cuda/transpose.cu(67): *error: identifier "getOutputMat" is undefined*
/Users/Hawk/Documents/study/DIP/OpenCV/OpenCVSource/modules/cudaarithm/src/cuda/transpose.cu(92): *error: identifier "syncOutput" is undefined*
Then what action I take:
check the code and I found these undefined symboles are defined in OpenCVSource/modules/core/include/opencv2/core/private.cuda.hpp
check the code and I confrim that the "transpose.cu" file include "opencv2/core/private.cuda.hpp"
check the building log, and I the confirm the private.cuda.hpp is in the search path of header file
cp "opencv2/core/private.cuda.hpp" as another file "opencv2/core/hawk.hpp", and then edit "transpose.cu" to include this new file, and I found
the "undifined symbole error" disapeared.
Although this is a workable workaround, I would like know whether the original OpenCV source cannot be compiled.

All, I think I found the problem cause.
Before I met such problem, I've already build and install OpenCV using older code from the git repo. So that there already have header files in my /usr/local/include/opencv2, especially there is /usr/local/include/opencv2/core/private.cuda.hpp.
However, it is an older one that doesn't define the symbols reporting undefined in above question. At the same time I found during the building nvcc have -I/usr/local/include in the command line, so that it use wrong private.cuda.hpp. As you know it should use the one in OpenCVSource, not the older installed one.
I think the solution is to gracefully remove the original installed OpenCV from my computer, then build again. I am trying and I will report later.

Related

Rails 7, vips on M1 MacBook Air

I'm unable to use Rails 7.0.3.1 with vips on an M1 MacBook Air due to the error:
rails aborted!
LoadError: Could not open library 'glib-2.0.0': dlopen(glib-2.0.0, 0x0005): tried: 'glib-2.0.0' (no such file), '/usr/local/lib/glib-2.0.0' (no such file), '/usr/lib/glib-2.0.0' (no such file), '/Users/brody/Code/tms.next-tms.com.wip2/glib-2.0.0' (no such file).
Could not open library '/opt/local/lib/libglib-2.0.0.dylib': dlopen(/opt/local/lib/libglib-2.0.0.dylib, 0x0005): tried: '/opt/local/lib/libglib-2.0.0.dylib' (mach-o file, but is an incompatible architecture (have (x86_64), need (arm64e)))
I'm using ffi 1.15.1 and can see it searching correctly in /opt/local/lib, but the homebrew package builds binaries for x86_64 rather than arm64e even while using the --build-from-source option (brew install vips --build-from-source).
Has anyone got this working?
I ran into the same issue (with libglib-2.0.0) but then I figured that brew poured glib--2.74.5.arm64_monterey.bottle so why does it find 2.0.0? In my case it was (a dated version of) Navicat linking an old glib
~$ ls -l /usr/local/lib/libglib*
0 lrwxr-xr-x 1 chaos staff 73B Dec 11 11:23 /usr/local/lib/libglib-2.0.0.dylib -> /Applications/Navicat Premium.app/Contents/Frameworks/libglib-2.0.0.dylib
This wasn't the only file however, Navicat linked a total of 71 dylib files. I removed all those symlinks and then the error disappeared

MacOS RStudio accessing wrong clang after upgrade to Catalina

After an upgrade to MacOS Catalina, I find that I can no longer install packages from source in the RStudio IDE (v1.2.5001, current stable release).
Example:
> install.packages("processx", type = "source")
trying URL 'https://cran.rstudio.com/src/contrib/processx_3.4.1.tar.gz'
Content type 'application/x-gzip' length 123430 bytes (120 KB)
==================================================
downloaded 120 KB
* installing *source* package ‘processx’ ...
** package ‘processx’ successfully unpacked and MD5 sums checked
** libs
/usr/local/clang4/bin/clang -Wall -g -O2 -Wall tools/px.c -o tools/px
make: *** [tools/px] Killed: 9
ERROR: compilation failed for package ‘processx’
* removing ‘/Library/Frameworks/R.framework/Versions/3.5/Resources/library/processx’
* restoring previous ‘/Library/Frameworks/R.framework/Versions/3.5/Resources/library/processx’
Warning in install.packages :
installation of package ‘processx’ had non-zero exit status
In the process I get a popup with this message:
“clang-4.0” cannot be opened because the developer cannot be verified.
It seems that RStudio is pointed at clang from XCode 11.1, rather than the clang 8 I got from CRAN https://cran.r-project.org/bin/macosx/tools/.
Straight from R (e.g. sudo -i R in my terminal) a source install works fine, so it seems to be a matter of getting RStudio to look in the right place for the clang binary.
Any ideas?
I changed my ~/.R/Makevars file to point to a newer version of clang (R recommends 8+), e.g. CC=/usr/local/opt/llvm/bin/clang. I commented out the clang4 lines and created a new set pointing to the updated clang. Worked like a charm, now able to install R packages as usual.
Note: I had previously used brew to update llvm, which installed clang9.
Hope that helps!

yocto SDK krogoth cmake FindBoost not found

I am trying to find the boost libraries (cmake) inside the Yocto SDK with extended environment on krogoth.
The default cmake Find_
find_package(Boost REQUIRED)
The standard error message
Unable to find the requested Boost libraries.
Unable to find the Boost header files. Please set BOOST_ROOT to the root
directory containing Boost or BOOST_INCLUDEDIR to the directory containing
Boost's headers.
Call Stack (most recent call first):
CMakeLists.txt:3 (find_package)
The following is a snippet from my conf/local.conf
IMAGE_INSTALL_append = " boost-dev"
IMAGE_INSTALL_append = " boost"
IMAGE_INSTALL_append = " kernel-devsrc"
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-module-hello"
KERNEL_MODULE_AUTO_lOAD += "hello-md"
LCHAIN_HOST_TASK_append = "${SDK_EXTRA_TOOLS}"
SDK_EXTRA_TOOLS = " nativesdk-cmake
I am using the native cmake
auke#xenialxerus:~/workspace/beaglebone-dev/build$ which cmake
/home/auke/workspace/beaglebone-dev/poky-sdk/tmp/sysroots/x86_64-linux/usr/bin/
since I:
source environment-setup-cortexa8hf-neon-poky-linux-gnueabi
looking for the usual headers in:
find ./tmp/sysroots/beaglebone/usr/include/boost/
..
/tmp/sysroots/beaglebone/usr/include/boost/vmd/list/to_seq.hpp
./tmp/sysroots/beaglebone/usr/include/boost/vmd/list/to_tuple.hpp
./tmp/sysroots/beaglebone/usr/include/boost/vmd/to_list.hpp
./tmp/sysroots/beaglebone/usr/include/boost/vmd/empty.hpp
./tmp/sysroots/beaglebone/usr/include/boost/vmd/is_list.hpp
./tmp/sysroots/beaglebone/usr/include/boost/vmd/size.hpp
./tmp/sysroots/beaglebone/usr/include/boost/vmd/get_type.hpp
./tmp/sysroots/beaglebone/usr/include/boost/vmd/assert_is_identifier.hpp
./tmp/sysroots/beaglebone/usr/include/boost/vmd/is_number.hpp
..
just like the binaries:
./tmp/sysroots/beaglebone/usr/lib/libboost_system-mt.a
./tmp/sysroots/beaglebone/usr/lib/libboost_iostreams.so.1.60.0
./tmp/sysroots/beaglebone/usr/lib/libboost_serialization-mt.a
./tmp/sysroots/beaglebone/usr/lib/libboost_date_time-mt.a
./tmp/sysroots/beaglebone/usr/lib/libboost_date_time.a
./tmp/sysroots/beaglebone/usr/lib/libboost_thread.so
./tmp/sysroots/beaglebone/usr/lib/libboost_signals-mt.a
./tmp/sysroots/beaglebone/usr/lib/libboost_date_time-mt.so
./tmp/sysroots/beaglebone/usr/lib/libboost_graph-mt.a
./tmp/sysroots/beaglebone/usr/lib/libboost_iostreams.so
./tmp/sysroots/beaglebone/usr/lib/libboost_regex.so
./tmp/sysroots/beaglebone/usr/lib/libboost_wserialization.so.1
Is there something that i might have overlooked?
regards Auke
You should use
bitbake -c populate_sdk <image_name> to generate the SDK based on your image;
As an alternative to locating and downloading a toolchain installer,
you can build the toolchain installer one of two ways if you have a
Build Directory:
*Use bitbake meta-toolchain. This method requires you to still install
the target sysroot by installing and extracting it separately. For
information on how to install the sysroot, see the "Extracting the
Root Filesystem" section.
*Use bitbake -c populate_sdk. This method has significant
advantages over the previous method because it results in a toolchain
installer that contains the sysroot that matches your target root
filesystem.
Also, using the variable TOOLCHAIN_HOST_TASK to add more packages.
http://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html
This variable lists packages the OpenEmbedded build system uses when
building an SDK, which contains a cross-development environment. The
packages specified by this variable are part of the toolchain set that
runs on the SDKMACHINE, and each package should usually have the
prefix "nativesdk-". When building an SDK using bitbake -c
populate_sdk , a default list of packages is set in this
variable, but you can add additional packages to the list.
e.g.
TOOLCHAIN_HOST_TASK += “nativesdk-libqt5core-dev”

OpenCV won't build with CUDA even though WITH_CUDA=ON in CMake

I have tried to build OpenCV 3.1 using CMake (the gui version) to enable Cuda. I have installed Cuda version 7.5 64-bit and CMake automatically found the correct path to the Cuda toolkit. I made sure that the WITH_CUDA value was set to ON, and pressed configure. This is what I got concerning Cuda:
CUDA detected: 7.5
CUDA NVCC target flags: -gencode;arch=compute_20,code=sm_20;-gencode;arch=compute_20,code=sm_21;-gencode;arch=compute_30,code=sm_30;-gencode;arch=compute_35,code=sm_35;-gencode;arch=compute_30,code=compute_30
...
Extra dependencies: comctl32 gdi32 ole32 setupapi ws2_32 vfw32 cudart nppc nppi npps cufft -LC:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v7.5/lib/x64
...
Other third-party libraries:
Use IPP: 9.0.1 [9.0.1]
at: C:/OpenCV-3.1.0/opencv/sources/3rdparty/ippicv/unpack/ippicv_win
Use IPP Async: NO
Use Eigen: NO
Use Cuda: YES (ver 7.5)
Use OpenCL: YES
Use custom HAL: NO
NVIDIA CUDA
Use CUFFT: YES
Use CUBLAS: NO
USE NVCUVID: NO
NVIDIA GPU arch: 20 21 30 35
NVIDIA PTX archs: 30
Use fast math: YES
Then I generate using Visual Studio 12 2013 Win64.
Next I open the newly generated OpenCV.sln project in Visual Studio 2013 and build the project. It completes without any errors, but 103 warnings like this:
LINK : warning LNK4044: unrecognized option '/LC:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v7.5/lib/x64'; ignored
OpenCV builds just fine and I can build programs with it. I can also include "opencv2/core/cuda.hpp" without any problem. However, when I try to use cuda::getDevice() i get this error:
OpenCV Error: No CUDA support (The library is compiled without CUDA support) in throw_no_cuda, file C:\builds\master_PackSlave-win64-vc12-shared\opencv\modules\core\include\opencv2/core/private.cuda.hpp, line 97
When I print the information from cv::getBuildInformation() i get:
Other third-party libraries:
Use IPP: 9.0.1 [9.0.1]
at: C:\builds\master_PackSlave-win64-vc12-shared\opencv\3rdparty/ippicv/unpack/ippicv_win
Use IPP Async: NO
Use Eigen: NO
Use Cuda: NO
Use OpenCL: YES
Use custom HAL: NO
It seems Cuda is disabled somewhere in the process, but I can't figure out why. I have tried to reconfigure and rebuild several times with the same results. Would love some help on this!
The problem is CMake: it generates wrong link options for Visual Studio.
LINK : warning LNK4044: unrecognized option '/LC:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v7.5/lib/x64'; ignored
It should be "LIBPATH:C:" instead of "LC:".
To fix the problem:
Generate the solution with CMake
Go to the build directory
Open an IDE/Text editor which is able to do a global search in this directory
For each occurrence of "-LC:" in any file, replace it by "-LIBPATH:C:".
========= EDIT =========
I found the problem, it is in CMakeLists.txt :
foreach(p ${CUDA_LIBS_PATH})
set(OPENCV_LINKER_LIBS ${OPENCV_LINKER_LIBS} -L${p})
endforeach()
Instead of using "${CMAKE_LIBRARY_PATH_FLAG}" which automatically put -LIBPATH, someone put "-L"...
So to fix it:
Open CMakeLists.txt
Replace "-L" by "${CMAKE_LIBRARY_PATH_FLAG}"
Configure & Generate the solution with CMake and compile with VS.
Hope it will help!
You can successfully compile OpenCV with Cuda after manually editing CMakeLists.txt as Dubrzr say.
Also You will have the same result if you download and compile OpenCV straight from github. It is already fixed.

Clang & LLVM building for SPARC

I'm writing a little self-educational project. It has to do with Clang and LLVM internals hacking.
But while I was investigating the code base and reading documentation, strange things were going on with the build process.
What I am trying to do for starters is to build LLVM and Clang for SPARC target. But this rather simple task turns out to be quiet challenging.
I use sources from the stable release 3.4.2 and folder tree looks like that:
llvm/
...
projects/
...
test-suite <-- test-suite-3.4.src.tar.gz extracted here
tools/
...
clang/ <-- cfe-3.4.2.src.tar.gz extracted here
....
tools/
....
extra <-- clang-tools-extra-3.4.src.tar.gz extracted here
And from the intermediate folder (which lays on the same level as llvm) I call the following:
../llvm/configure --disable-optimized --enable-targets=sparc \
--prefix=/home/wf34/projects/helloClang/built
Surprisingly, resulting clang and llvm cannot deal with SPARC arch.
../built/bin/clang file2.c -S --target=sparc-unknown-linux -emit-llvm -o -
Gives (amongst the others) following line:
clang: warning: unknown platform, assuming -mfloat-abi=soft
Result is the same, if I write just --target=sparc.
Finally, attaching result of the llc --version:
LLVM (http://llvm.org/):
LLVM version 3.3
Optimized build.
Default target: x86_64-pc-linux-gnu
Host CPU: corei7-avx
Registered Targets:
cpp - C++ backend
x86 - 32-bit X86: Pentium-Pro and above
x86-64 - 64-bit X86: EM64T and AMD64
Thank you for your insight and ideas!
Edit
Actually, having all that written, I have a guess that maybe I might have been mistaken while getting and untaring and setting the source from stable release. Maybe I would be better off following manual steps directly and getting source from svn trunk. I will fall back to that option if I won't receive any more meaningful suggestion.

Resources