I tried to run the kuka simulation in drake from both source and the binary release but it fails.
The error message is :
ERROR: In /vtk/IO/Import/vtkOBJImporter.cxx, line 495
vtkOBJPolyDataProcessor (0x55bb85982d30): Error reading 'v' at line 3
I checked a similar question but my libvtkIOGeometry is found in the drake library when I strace the command.
When running from binary , a warning shows :
[console] [warning] The use of kuka_simulation outside of Drake (i.e., via 'make install' or a pre-compiled release image) is deprecated and will be removed from the install on or after 2022-01-01
Is it a problem in my installation or is there a problem in this example ? I have Ubuntu 18.04.6 LTS, bazel 4.2.1, gcc 7.5.0, python 3.6.9 and last stable drake release.
Is there any chance that your workstation or shell terminal is set to use a non-ASCII locale, where a period . is not the decimal fraction separator?
Related
We want to use a Mac Mini with the M1 processor as an agent in our CI pipeline to make sure that developers with new Macs can compile the project. We duplicated the setup that we have for x86, but cmake cannot find libraries such as boost:
CMake Error at /opt/homebrew/Cellar/cmake/3.19.7/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:218 (message):
Could NOT find Boost (missing: Boost_INCLUDE_DIR container system
date_time)
Weirdly, this is not an issue when connecting to the machine directly via ssh. Even manually setting the environment variables does not change anything.
The Jenkins agent uses Java. If you install Java via brew (e.g., adoptopenjdk8), you might get an x64 version (as of March 2021) that is run using the Rosetta translation layer. You can verify this by executing sysctl sysctl.proc_translated. In the "normal" SSH connection, this should return 0, when executed as sh "sysctl sysctl.proc_translated" in Jenkins, you will see a 1.
Preferred Option (install native JDK)
Instead of using, e.g., adoptopenjdk8, you can install the zulu JDK, which is available natively, via
brew install --cask zulu
After this, you should be able to verify that proc_translated is 0 within Jenkins. You can verify that a native binary is built as described below.
Hotfix (without changing the JDK)
The following is a hotfix if you cannot install a native JDK.
We were able to force cmake to run natively (and thus to find the native libraries) by modifying our Jenkinsfile as follows:
old:
sh "cmake .."
sh "make hyriseTest"
new:
sh "PATH=/opt/homebrew/bin:$PATH arch -arm64 cmake .."
sh "arch -arm64 make hyriseTest"
Having to repeat the arch command over and over is not really pretty. Maybe someone has a better solution.
Verification of the result
We can verify that our generated binary is a native ARM binary:
sh "file hyriseTest"
Result:
+ file ./hyriseTest
./hyriseTest: Mach-O 64-bit executable arm64
Compiler warnings
Note: We are still seeing linker warnings about "ltmp3" and "ltmp4". I have not found any information about that online and it does not seem to affect the correctness of the result. Example:
ld: warning: direct access in function 'ltmp4' from file 'CMakeFiles/hyriseMvccDeletePlugin.dir/Unity/unity_0_cxx.cxx.o' to global weak symbol
I have installed CUDA 8.0 on ubuntu and set the environment variable in .bashrc as below:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/cuda/lib64
export CUDA_HOME=/usr/local/cuda
export PATH=$PATH:/usr/local/cuda/bin
Also, when I run
nvcc --version
I can find the correct version of CUDA.
However, it always shows "use cuda: NO" when I try to run "cmake .." inside opencv 3.3 directory.
Can anyone solve this problem? Thanks.
ps:
1. When I compile caffe, cmake can find CUDA correctly. It gets more confusing.
2. When I check OpenCVDetectCUDA.cmake, I found the following phrase sentence:
if(CMAKE_COMPILER_IS_GNUCXX AND NOT APPLE AND CMAKE_CXX_COMPILER_ID STREQUAL "Clang")
message(STATUS "CUDA compilation is disabled (due to Clang unsupported on your platform).")
return()
endif()
Then I comment this paragraph, cmake can find CUDA. I am not sure what effect it will cause in later compilation and use.
If building from source is giving you as issue try installing via pip:
$ pip install opencv-python
I suspect the reason why you are having issues with building your opencv is because of the source of your files.
I am trying to install clang from source following the instructions as given in http://clang.llvm.org/get_started.html ( Steps 1-4 and 7) in Ubuntu 14.04
Inside the build directory , I ran make which succeeded. I wasn't sure what to do after that , so I ran make install inside the build directory, following which I got this cmake error:
There is no executable named clang in /build/bin folder anyway, but I can find others like clang-check, clang-query, etc. What's going wrong?
PS: My main requirment is to experiment with alpha security checkers of clang analyzer and also write my own checker later.
I am new to Ubuntu and OpenCV. Apologies for my amateurishness.
I think I messed up OpenCV installation.
I had installed OpenCV 2.4 months back. The installation was successful (built openCV from source using CMake)
Couple of days back I had also installed OpenCV 3.0 using the same procedure.
The problem began when one of my code gave a segmentation fault for seemingly no reason. On suggestion by a friend on Caffe Neural Network issues forum (https://github.com/BVLC/caffe/issues/3416), it seems that I am compiling with 3.0 headers but linking against the 2.4 libraries.
I checked /usr/local/include. It has the standard openCv header files ( I didn't understand what 'compiling with 3.0 header means' )
In /usr/local/lib I have OpenCV 3.0 libraries ( no 2.4.8 at all).
Now compilation was successful, but when I try to run it, I get the following error.
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff76c49bc in cv::merge(cv::_InputArray const&,
cv::_OutputArray const&) ()
from /usr/lib/x86_64-linux-gnu/libopencv_core.so.2.4
Just to add
"pkg-config --modversion opencv"
3.0.0
whereas dpkg -l | grep libopencv
gave out
i libopencv-calib3d-dev:amd64 2.4.8+dfsg1-2ubuntu1 amd64 development files for libopencv-calib3d
ii libopencv-calib3d2.4:amd64 2.4.8+dfsg1-2ubuntu1 amd64 computer vision Camera Calibration library
ii libopencv-contrib-dev:amd64 2.4.8+dfsg1-2ubuntu1 amd64 development files for libopencv-contrib
.......
q.1> why does my code link to libopencv_core.so.2.4 instead of 3.0. I have checked in /usr/local/lib and did not see a single 2.4 library. I have tried manually defining links to header files and libraries in CMake but still same result.
q.2> Do OpenCV headers have a version number? I don't understand how they are called '2.4 headers'. I have checked the source code but did not see any specific requirement for a version of library. Then what dictates to link to 2.4 version libraries?
Sorry if this is theoretical but this would be highly beneficial to beginners like me. Please do comment for a suitable question title if the current one is not appropriate.
Thanks
Your opencv2.4 libraries are located in /usr/lib/x86_64-linux-gnu/ while the new opencv3 libraries are most likely located in /usr/local/lib. The linker is first looking in the /usr/lib/x86_64-linux-gnu/ directory, and thus finding the opencv2.4 libs first. To fix this you can tell the linker to look in /usr/local/lib first by adding the following to your ~/.bashrc file
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH
Reload the bashrc file in the terminal as follows (or simply close and re-open the terminal):
source ~/.bashrc
And update the library database:
sudo ldconfig
To check the order in which the linker will search for libraries, you can use the following:
ld -lopencv_core --verbose | grep attempt
I'm running the cross compiled version of Dart runtime. The executable has been produced using the following instructions: https://code.google.com/p/dart/wiki/RaspberryPi
When I run it I get this error:
-bash: ./dart: No such file or directory
ldd output:
pi#raspberrypi ~/dart/runtime $ ldd dart
not a dynamic executable
file output:
pi#raspberrypi ~/dart/runtime $ file dart
dart: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0xb0dc8037ff83ff0742749241be56d7b8935efa6f, not stripped
Not really an answer but I've found that using the last release of Raspbian (Debian Wheezy 2014-09-09) the executable works fine. So I think the cause is something old in my current Raspbian installation (I've updated it with the last updates but it is not sufficient).