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.
Related
I'm running Centos 7 and am trying to build hipSYCL (see here)
The issue is that hipSYCL needs to have cmake info from the LLVM build (via the LLVM_DIR cmake variable).
This is problematic for me because building LLVM requires a massive 35Gb for the libraries and exes. I don't have that much memory to spare.
I did find a build of llvm-toolset-8.0 online for Centos 7 and installed it, but to my surprise, that didn't seem to work with LLVM_DIR because there's no cmake files (since I didn't build it locally).
So, my question would be, is there a way to build hipSYCL using pre-built LLVM-clang?
If I'm missing or misunderstanding something, I'd appreciate any help.
LLVM publishes the necessary cmake files, and the binary OS packages I've seen include it, generally in a directory called /usr/lib/llvm*/lib/cmake and in a package called something like llvm-*-dev.
it throws an error while starting that libgtk3 cannot be find.
Is it possible to build an electron app to work on systems with libgtk2?
Actually it would be perfect if AppImage included all nesessary lib dependencies(like fuse for example), even if it would be a big filesize of image.
According to issue #10780 on GitHub, Electron upgraded back in 2017 to Chrome 61, which requires GTK+ 3. Therefore it is not possible to run Electron on a system with only GTK+ 2 installed.
The idea of AppImages is that an application should contain all libraries it needs to run. However, libraries like GTK+ need to integrate deeply into the system (GTK+ requires libXrandr.so, libglib.so, etc. just to name a few) and have a ton of dependencies which would blow the package up. It is therefore pretty difficult to build an app which contains all different dependencies it has (and even imagine having three or more AppImages containing GTK+ and dependencies sitting on your hard drive).
And in the case of GTK+, it is in most use-cases not enough to just install libgtk (any version), because you might want to profit from dependencies which are just "recommended".
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 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 am using open source C++ library DCMTK from http://dicom.offis.de/dcmtk.php.en.
I have successfully compiled this library on Windows using VC++ IDE, MacOS Xcode, Mac iOS simulator.
But I am not able to compile this library on iOS device as it is ARM based architecture.
DCMTK library compiled very well on Intel architecture.
Now my problem statement is :-
I need to compile this DCMTK C++ library on ARM architecture by cross compilation.
I am using Ubuntu 64 bit machine for cross compilation.
I have installed binaries from GNU ARM tool chain from http://www.gnuarm.com/
I am using GCC toolchain 4.0 binutils-2.16.1, gcc-4.0.2-c-c++, newlib-1.14.0, insight-6.4, TAR BZ2 [65.5MB] binaries for Ubuntu 64 bit machine for ARM cross compilation.
After Installing these binaries on Ubuntu I have set PATH environment variable to
PATH=$PATH/gnu_arm/bin
For configuring the DCMTK C++ library I have run the following command on shell
CC=arm-elf-gcc CXX=arm-elf-g++ AR=arm-elf-ar RANLIB=arm-elf-ranlib ARFLAGS=cruv ./configure –prefix=$home_dicom –target=arm-elf –host=arm-elf –enable-std-includes –disable-threads
It creates a make file properly. Now I am trying to compile the code by using make command, but facing so many compilation errors like :-
1) I tried to compile my first dependent C++ library that is ofstd.
I got error for DIR*, struct dirent, opendir(), closedir() calls.
It includes for these calls, but I did not found any definitions for the above calls in this header file.
2) When I compile another library oflog I got the following errors like
error: nthos was not declared in this scope
error: ntohl was not declared in this scope
error: htons was not declared in this scope
error: htonl was not declared in this scope.
These calls are networking calls and are not defined in any of the header file from GNU ARM tool.
I tried to download the sources of ARM binaries and extracted the tar files and try to copy missing header files to installed GNU ARM on Ubuntu.
For some files it compiles after doing changes to copied header files, and for some again it gives compilation errors.. There is a loop of compilation errors for every file present under DCMTK library as some of the standard header files are missing.
Please suggest if there is any other tool chain available for ARM cross compilation on Ubuntu 64 bit machine.
Or any other good solution apart from this.
Thanks!!!
Amit
There are many areas for problems when it comes to cross compiling. There are three main flags for cross compiling. -host , -target, and -build. The -host flash is the machine in which the resulting binaries will run on. The -build flash is the system in which you will be compiling on. The -target flag is for building libraries that will be used in cross compiling. So if you were to build your own gcc tool chain. So in your case you won't set the target flag as we're not building a tool chain. the -host flag will be arm-elf. And the -build flag will be amd64.
Usually a cross compilation fails if there are inconsistencies between the regular c compiler and the cross compiler. I have compiled several libraries for the avr32 with a toolchain generated by buildroot, but in some cases (socat project for example) it hasn't been possible.
Your host, your target and the CXX flags look ok. I think it is not necessary to put the AR flag (that is the idea with the host and target option).
In other hand, this is an example for the expat libraries for the avr32:
./configure --host=avr32-linux --prefix=/home/juan/builds/build_expat/ CC=avr32-linux-gcc
make; make install
I can recommend you that tries to cross compile from an ia32 architecture. I had several problems with that ubuntu in the past.