How to compile the necessary kernel module file for beaglebone black? What are the compiled kernel files to copy to the target?
make modules_install INSTALL_MOD_PATH=$TARGETDIR generated huge number of files
If you want to cross compile to build the kernel, you can use this inside your linux kernel downloaded files
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- modules
Related
Edit:
Problem solved after a few steps. You can take a look at my post on the OpenCV Q&A page.
http://answers.opencv.org/question/152366/build-application-with-static-libraries/
I'm trying to statically link my C++ (CMake) application to run on another computer which does not have OpenCV installed.
So far,
I built OpenCV from source by setting BUILD_SHARED_LIBS to OFF, so I can see library files under lib directory. (with .a extension)
I edited the environment variable for the new build of OpenCV, my IDE does see include directories and files, so this step also seems ok.
Added "-static" parameter to target_link_libraries command in CMake:
target_link_libraries(HoGPeopleDetector ${OpenCV_LIBS} "-static")
Then rebuilt the application, EXE size increased to 1.6 MB from 200 KB. So I guess linking process was successful.
The application works well when I run it within my IDE. However, when I try to run it from the EXE file, it still expects DLL files. (libopencv_core310.dll and maybe more)
IDE: CLion 2017.1.2 OpenCV: 3.1
Problem solved after a few steps. You can take a look at my post on the OpenCV Q&A page.
http://answers.opencv.org/question/152366/build-application-with-static-libraries/
Overall, it was "remember to clear your CMake cache file between each invocation of cmake" and to move/copy the opencv_ffmpegXXX.dll (310 in my case), put it in the same directory with your EXE.
I'm attempting to use OpenCV for Windows as supplied by opencv.org in a project I'm building with JetBrains' CLion IDE. I've installed the opencv library and configured CLion (set(OpenCV_DIR) to reference the build directory under it, but CMake issues the warning:
Found OpenCV Windows Pack but it has no binaries compatible with your configuration.
You should manually point CMake variable OpenCV_DIR to your build of OpenCV library.
I've tried some of the older distributions from opencv.org with the same results. It appears CMake is locating the OpenCV libraries, but doesn't want to use them. Why, and how do I get the OpenCV libraries to work under CLion?
The short answer is, you will probably need to build OpenCV from source in order to use it with CLion. But given the number and range of partially answered and unanswered questions here* and elsewhere on using JetBrains' CLion IDE with the OpenCV library, I think an overview is needed (my notes are from CLion 2016.3 and OpenCV 3.1, YMMV):
Though not produced by JetBrains, CMake is very central to CLion's operation. Understanding CMake therefore helps greatly in diagnosing CLion build problems. In particular CMake maintains a disk "cache" of settings which you may need to clear to incorporate changes to your environment (Tools->CMake->Reset Cache and Reload Project).
To make use of OpenCV in your build you must specify it in your project's CMakeLists.txt file. You request that CMake locate your OpenCV location and link it to your TARGET. An example of a sequence of commands from CMakeLists.txt for an executable named mushroom follows:
add_executable(mushroom ${SOURCE_FILES})
FIND_PACKAGE(OpenCV REQUIRED)
TARGET_LINK_LIBRARIES(mushroom ${OpenCV_LIBS})
(For more on FIND_PACKAGE, see CMake:How To Find Libraries.)
FIND_PACKAGE for package XXX works either by way of FindXXX.cmake files located at CMake's Modules directory, or by consulting environment variable XXXX_DIR. On my system, no FindOpenCV.cmake file was present, so I relied on the OpenCV_DIR environment variable instead. This must be set, not to the root of your OpenCV installation, but to the build folder beneath it. I used an entry in CMakeLists.txt to set this variable, e.g.:
set(OpenCV_DIR C:/Users/myacct/AppData/Local/opencv-3.0.0/build)
To link with OpenCV, CMake uses either FindOpenCV.cmake or OpenCV_DIR (see previous point above) to locate a file named OpenCVConfig.cmake. This file is generated by and ships with a particular build of OpenCV in order to document what components are present and where they are located.
Problems may occur when variable names used by OpenCVConfig.cmake conflict with those CLion has stored in its environment. In particular, if your OpenCV was built by Microsoft Visual C (MSVC), as is the Windows distribution from opencv.org, it won't work with CLion.
Because CLion's build toolchain (ControlAltS-toolchain) uses either MinGW or Cygwin, OpenCVConfig.cmake will search for OpenCV binaries under a subdirectory named mingw or cygwin and will find none because the binaries were built with MSVC (it will look in a directory like vc11 or vc12 instead). This probably means you will need to build OpenCV from source in order to use it with CLion.
Would reconfiguring OpenCVConfig.cmake to point to the MSVC binaries make this work? you may ask. Unfortunately the answer is still no, because libraries built with one compiler typically cannot be linked with another one.
OpenCVConfig.cmake or FindOpenCV.cmake likely contain diagnostic messages, but when CLion executes CMake for you, message(STATUS) calls are not displayed. To make them display, change them to message(WARNING) or message(FATAL_ERROR). But CLion 2016.3 EAP relieves this problem; see https://stackoverflow.com/a/39398373/5025060.
CLion does not indicate which .cmake script issued which diagnostics; don't assume they all come from the same script.
Hopefully this provides some general guidance on resolving CLion / CMake / OpenCV compatibility problems. Note that this does not cover compiler or linker issues; these will not appear until CMake completes its initial makefile build. Compiler or linker issues occur at a later stage and are controlled by include*(), link*() and other commands in CMakeLists.txt.
*Some related SO questions:
OpenCV Windows setup with CLion
OpenCV CLion (Cmake) linking issue - cmake reports a strange error
use OpenCV with Clion IDE on Windows
Compiling OpenCV on Windows with MinGW
Could not find module FindOpenCV.cmake ( Error in configuration process)
CMake: Of what use is find_package() if you need to specify CMAKE_MODULE_PATH anyway?
I am confused about build_dir and staging_dir in openwrt buildroot.
What are they used for?
There are feeds in openwrt. I would imagine to build an image. You will select the packages you want in menuconfig and use make to build it.
The packages are fetched from feeds and then compiled into build_dir?
Then what is staging_dir used for?
The directory build_dir is used to unpack all the source archives and to compile them in.
The directory staging_dir is used to "install" all the compiled programs into, ready either for use in building further packages, or for preparing the firmware image.
There are three areas under build_dir:
build_dir/host, for compiling all the tools that run on the host computer (OpenWRT builds its own version of sed and many other tools from source). This area will be use for compiling programs that run only on your host.
build_dir/toolchain... for compiling the cross-C compiler and C standard library components that will be used to build the packages. This area will be use for compiling programs that run only on your host (the cross C compiler, for example) and also, libraries designed to run on the target that are linked to - e.g. uClibc, libm, pthreads, etc.
build_dir/target... for compiling the actual packages, and the Linux kernel, for the target system
Under staging, there are also three areas:
staging_dir/host is a mini Linux root with its own bin/, lib/, etc. that the host tools are installed into; the rest of the build system then prefixes its PATH with directories in this area
staging_dir/toolchain... is a mini Linux root with its own bin/, lib/, etc that contains the cross C compiler used to build the rest of the firmware. You can actually use that to compile simple C programs outside of OpenWRT that can be loaded onto the firmware. The C compiler might be something like: staging_dir/toolchain-mips_34kc_gcc-4.8-linaro_uClibc-0.9.33.2/bin/mips-openwrt-linux-uclibc-gcc. You can see the version of the CPU, the C library and gcc encoded into it; this allows multiple targets to be built in the same area concurrently.
staging_dir/target.../root-... contains 'installed' versions of each target package again arranged with bin/, lib/, this will become the actual root directory that with some tweaking will get zipped up into the firmware image, something like root-ar71xx. There are some other files in staging_dir/target... primarily used for generating the packages and development packages, etc.
Sorry its a bit verbose, this is hard to describe more succinctly.
I am trying to build an OS image for TI OMAP4 Pandaboard. The downloaded BSP can be built but very limited without gcc g++ compiler. I think it much difficult to add the tool chain in QNX Momentics IDE, because there are so many files to be added. Can I manually modify the buildfile to do it? If possible, please give me an example. Thanks in advance.
No, it is not possible to run g++ on your TI OMAP4 Pandaboard (unless you build g++ from sources for the ARM platform using the existing QNX toolchain running on an X86 platform).
Why not possible: QNX releases their build tools only for X86-based hosts. The currently supported host OS-es include some variants of Windows, Linux and QNX but the precondition is that the host hardware is X86-based.
Likely you do not actually want to build your library on the target hardware; it should not matter where you actually do the build (except in very special cases where you build some source code based on user input, etc.)
What you need to do is build your library on your development host using the ARM toolchain (QCC if you want to use the high-level tools; ntoarmv7-g++ if you want to use the familiar g++ interface). Once you have your binary you can include it in the .ifs file. You just need to include a line in the .build file, similar to the following example:
/path/on/targetfs/yourbinary=/path/on/buildmachine/yourbinary
If your build environment is configured so that mkifs finds your binary then you can omit the "path/on/buildmachine" part.
If you are fine with having the binary on your target under /proc/boot then you can omit the "/path/on/targetfs/ part as well.
For ease of development it would usually be more convenient for you to store your binary on the SD card with a FAT filesystem. Then you can just copy your binary to the SD without having to rebuild the .ifs file.
Finally, once you get experienced you will want to export a part of your host-machine's filesystem via CIFS or NFS and mount it directly from your target. This will save all the trouble of having to copy files (and, possibly, reboot the target) in each build cycle. But this is far off from your original question.
I think you are trying to get the QNX C/C++ compiler to run on your target board. Correct?
If so, rather than installing the Runtime Kit, you install the QNX Software Development Platform and you should be good to go.
You can also use the System Builder to customize your QNX OS, but this is going to be harder than just using the QNX SDP.
One other note: QNX uses qcc for C and QCC for C++ instead of gcc. They both use gcc under the hood, but to compile on QNX, use qcc instead of gcc.
I need to use the traincascade and createsamples utilities.
I need to do this on many computers and do not want to have to build them myself as these computers do not have any development tools.
I have searched for instructions a lot, but they all say things like 'run the installer and install to Program Files' . Except that I don't see any installer. I have downloaded a 200MB exe OpenCV-2.4.0.exe, but on running it just extracts to some folder. That folder contains sources and cmake files, but I do not want to build myself. The library files are there, but no exe files (for traincascade and createsamples).
build a 64 bit version and a 32 bit version on the lowest os you can find(xp, vista or 7), then build your own installer.