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.
Related
I got a C++ project for Bazel, which by default builds for 64-bit Windows on my machine. However, I want to create a 32-bit executable, which, according to the documentation, is supported.
I have tried these commands:
bazel build :knusperli --platforms #bazel_tools//platforms:x86_32
Target #bazel_tools//platforms:x86_32 was referenced as a platform, but does not provide PlatformInfo
bazel build :knusperli --cpu i386_windows
ERROR: No toolchain found for cpu 'i386_windows'.
I thought, since Visual Studio can build 32-bit executables, it would be easy in Bazel as well, but I can't find any information on how to actually do this.
Bazel does not support building 32-bit binaries out-of-the-box. It's possible to add support via a custom CROSSTOOL file.
See:
https://github.com/bazelbuild/bazel/wiki/About-the-CROSSTOOL
https://github.com/bazelbuild/bazel/wiki/Building-with-a-custom-toolchain
https://github.com/bazelbuild/bazel/wiki/Yet-Another-CROSSTOOL-Writing-Tutorial
I'm interested in incorporating TensorFlow into a C++ server application built in Visual Studio on Windows 10 and I need to know if that's possible.
Google recently announced Windows support for TensorFlow: https://developers.googleblog.com/2016/11/tensorflow-0-12-adds-support-for-windows.html
but from what I can tell this is just a pip install for the more commonly used Python package, and to use the C++ API you need to build the repo from source yourself: How to build and use Google TensorFlow C++ api
I tried building the project myself using bazel, but ran into issues trying to configure the build.
Is there a way to get TensorFlow C++ to work in native Windows (not using Docker or the new Windows 10 Linux subsystem, as I've seen others post about)?
Thanks,
Ian
It is certainly possible to use TensorFlow's C++ API on Windows, but it is not currently very easy. Right now, the easiest way to build against the C++ API on Windows would be to build with CMake, and adapt the CMake rules for the tf_tutorials_example_trainer project (see the source code here). Building with CMake will give you a Visual Studio project in which you can implement your C++ TensorFlow program.
Note that the tf_tutorials_example_trainer project builds a Console Application that statically links all of the TensorFlow runtime into your program. At present we have not written the necessary rules to create a reusable TensorFlow DLL, although this would be technially possible: for example, the Python extension is a DLL that includes the runtime, but does not export the necessary symbols to use TensorFlow's C or C++ APIs directly.
There is a detailed guide by Joe Antognini and a similar TensorFlow ReadMe at GitHub explaining the building of TensorFlow source via CMake. You also need to have SWIG installed on your machine which allows connecting C/C++ source with the Python scripting language. I did use Visual CMAKE (cmake-gui) with the screen capture shown below.
In the CMake configuration, I used Visual Studio 15 2017 compiler. Once this stage successfully completes, you can click on the Generate button to go ahead with the actual build process.
However, on Visual Studio 2015, when I attempted building via the "ALL_BUILD" project, the setup gave me "build tools for v141 cannot be found" error. This did not go away even when I attempted to retarget my solution. Finally, the solution got built successfully with Visual Studio 2017. You also need to manually set the SWIG_EXECUTABLE path in CMake before it successfully configures.
As indicated in the Antognini link, for me the build took about half an hour on a 16GB RAM, Core i7 machine. Once done, you might want to validate your build by attempting to run the tf_tutorials_example_trainer.exe file.
Hope this helps!
For our latest work on building TensorFlow C++ API on Windows, please look at this github page. This works on Windows 10, currently without CUDA support (only CPU).
PS:
Only the bazel build method works, because CMake is not supported and not maintained anymore, resulting in CMake configuration errors.
I had to use a downgraded version of my Visual Studio 2017 (from 15.7.5 to 15.4) by adding "VC++ 2017 version 15.4 v14.11 toolset" through the installer (Individual Components tab).
The cmake command which worked for me was:
cmake .. -A x64 -DCMAKE_BUILD_TYPE=Release ^
-T "v141,version=14.11" ^
-DSWIG_EXECUTABLE="C:/Program Files/swigwin-3.0.12/swig.exe" ^
-DPYTHON_EXECUTABLE="C:/Program Files/Python/python.exe" ^
-DPYTHON_LIBRARIES="C:/Program Files/Python/libs/python27.lib" ^
-Dtensorflow_ENABLE_GPU=ON ^
-DCUDNN_HOME="C:/Program Files/cudnn-9.2-windows10-x64-v7.1/cuda" ^
-DCUDA_TOOLKIT_ROOT_DIR="C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v9.0"
After the build, open tensorflow.sln in Visual Studio and build ALL_BUILD.
If you want to enable GPU computation, do check your Graphics Card here (Compute Capability > 3.5). Do remember to install all the packages (Cuda Toolkit 9.0, cuDNN, Python 3.7, SWIG, Git, CMake...) and add the paths to the environment variable in the beginning.
I made a README detailing how to I built the Tensorflow dll and .lib file for the C++ API on Windows with GPU support building from source with Bazel. Tensorflow version 1.14
The tutorial is step by step and starts at the very beginning, so you may have to scroll down past steps you have already done, like checking your hardware, installing Bazel etc.
Here is the url: https://github.com/sitting-duck/stuff/tree/master/ai/tensorflow/build_tensorflow_1.14_source_for_Windows
Probably you will want to scroll all the way down to this part:
https://github.com/sitting-duck/stuff/tree/master/ai/tensorflow/build_tensorflow_1.14_source_for_Windows#step-7-build-the-dll
It shows how to pass command to create .lib and .dll.
Then to test your .lib you should link it into your c++ project,
Then it will show you how to identify and fix the missing symbols using the TF_EXPORT macro
I am actively working on making this tutorial better so feel free to leave comments on this answer if you are having problems.
is it possible to compile stm32 code on beaglebone (possibly black)?
As it seems platform has to have access to arm-none-eabi-gcc to be able to compile for stm32?
Basically, yes you can.
In order to compile code for stm32 family of mcus you would need a cross-compiler. if you run linux on your beaglebone board you can simply download premade toolchain for your distribution. if you dont find any, you would just build a compiler from source by specifying host and target.
https://wiki.osdev.org/GCC_Cross-Compiler#Preparing_for_the_build this article will help you build a gcc cross compiler for every supported target and host. it takes less then 15 mins.
Few things to note here, once you build your cross compiler, you wont have any kind of libc shiped with it. so get one on github (there are few). your options would be libc or libc-nano (which talks for it self). And from there you will be able to compile code for your stm32 mcu.
For example i ran ubuntu server on my beaglebone black, so in order to compile for stm32 on that, i installed armv7-A gcc compiler, so i can compile for beaglebone it self. then i downloaded source at https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads compile the source and you will have an official arm toolchain for microcontrollers.
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 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.