Compiling issue with Boost asio - boost

My goal is to cross-compile a code file with Yocto SDK on my host machine to make it executable on my target Board. I am using SUMO Yocto version and GCC 7.3 cross compiler.
First of all, to get with YOCTO cross compiling I created a file Hello.c :
#include <stdio.h>
int main(void)
{
printf ("Hello World!\n");
return 0;
}
I compiled the file executing :
make hello
Now I have a compiled file which is ready to be executed on my target board.
But now I have multiple .h files and multiple .cpp files and a main file.
When I execute main file like this :
make main
an error occurs:
main.cpp:10:10: fatal error: boost/asio.hpp: No such file or directory
include ^~~~~~~~~~~~~~~~ compilation terminated.
: recipe for target 'main' failed make: *** [main] Error 1
I think that I have a problem with Boost and asio.hpp.
Is the boost library included in my Yocto Linux image ?
What is the problem with asio.hpp ?
How can I fix this please ?
Thanks

I just noticed that, actually, you're not using the SDK but the toolchain which only includes glibc along with some basic tools and gdb; usually used to build test apps and debug. So that, you need to build the real SDK which contains, in addition to the toolchain, the dev version (libs/headers/other files) of the packages installed in the rootfs of your image. This can be accomplished by:
bitbake -c populate_sdk <your_image>
Once the SDK is built you need to install it through the generated installer script. Also, don't forget to source the environment setup script before you start to work!
For further information refer to https://www.yoctoproject.org/docs/latest/sdk-manual/sdk-manual.html#sdk-building-an-sdk-installer

Related

CMake: The C Compiler is not able to compile a simple test program

I am trying to cross-compile the Azure IoT SDK C for a Mips processor. Cross-compiling an older version of the same SDK using an older version of CMake (2.8.12.2) works just fine, so I doubt it's the code itself. I am guessing it's the Mips GCC compiler.
Error message:
CMake Error at /usr/share/cmake-3.10/Modules/CMakeTestCCompiler.cmake:52 (message):
The C compiler
"/usr/local/mipsisa32r2el/r23/bin/mipsisa32r2el-axis-linux-gnu-gcc"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: /home/axis/azure-iot-sdk-c/cmake/iotsdk_linux/CMakeFiles/CMakeTmp
Run Build Command:"/usr/bin/make" "cmTC_2cc84/fast"
/usr/bin/make -f CMakeFiles/cmTC_2cc84.dir/build.make CMakeFiles/cmTC_2cc84.dir/build
make[1]: Entering directory '/home/axis/azure-iot-sdk-c/cmake/iotsdk_linux/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_2cc84.dir/testCCompiler.c.o
/usr/local/mipsisa32r2el/r23/bin/mipsisa32r2el-axis-linux-gnu-gcc --sysroot=/usr/local/mipsisa32r2el/r23 -o CMakeFiles/cmTC_2cc84.dir/testCCompiler.c.o -c /home/axis/azure-iot-sdk-c/cmake/iotsdk_linux/CMakeFiles/CMakeTmp/testCCompiler.c
Linking C executable cmTC_2cc84
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_2cc84.dir/link.txt --verbose=1
/usr/local/mipsisa32r2el/r23/bin/mipsisa32r2el-axis-linux-gnu-gcc --sysroot=/usr/local/mipsisa32r2el/r23 -rdynamic CMakeFiles/cmTC_2cc84.dir/testCCompiler.c.o -o cmTC_2cc84
/usr/local/mipsisa32r2el/r23/lib/gcc/mipsisa32r2el-axis-linux-gnu/4.7.2/../../../../mipsisa32r2el-axis-linux-gnu/bin/ld: this linker was not configured to use sysroots
collect2: error: ld returned 1 exit status
CMakeFiles/cmTC_2cc84.dir/build.make:97: recipe for target 'cmTC_2cc84' failed
make[1]: *** [cmTC_2cc84] Error 1
make[1]: Leaving directory '/home/axis/azure-iot-sdk-c/cmake/iotsdk_linux/CMakeFiles/CMakeTmp'
Makefile:126: recipe for target 'cmTC_2cc84/fast' failed
make: *** [cmTC_2cc84/fast] Error 2
Unfortunately, I am stuck with the Mips GCC compiler I have. Is there a way to disable this test-program check?
Solution was to add these to the toolchain-file:
SET (CMAKE_C_COMPILER_WORKS 1)
SET (CMAKE_CXX_COMPILER_WORKS 1)
CMake tries to compile an executable using "standard" (as per what CMake thinks is standard) compiler options and tries to run that executable, so to see if the compiler is working. The executable is simple like int main(int argc, char *argv[]) { return argc - 1; }.
You can't do that when cross-compiling. Because usually you can't link with a proper C standard library, you don't have printf, or _start or _exit or similar, passing arguments to main is implementation-defined, or you need a special linker script, or there's no emulator for your architecture, so can't run cross-compiled source on the host, etc... Simply: you usually can't run the cross-compiled executable on the host, and most of the time even the compilation is hard enough to do.
The common solution is to set before project():
set(CMAKE_TRY_COMPILE_TARGET_TYPE "STATIC_LIBRARY")
So that CMake will try to compile a static library not an executable, as explained in cmake docs CMAKE_TRY_COMPILE_TARGET_TYPE. This avoids running the linker and is intended for cross-compiling.
You can set CMAKE_C_COMPILER_WORKS and it will omit the check in CMakeTestCCompiler.cmake, but CMAKE_TRY_COMPILE_TARGET_TYPE is a more proper solution.
Well this problem is really annoying, i faced this issue for 2 day now I got solution.
Let me explain my issue first
When I delete NDK and Cmake from Sdk folder and Run my application then grable install NDK and Cmake again.
Only that time Application run and when try to run again i get this error The C Compiler is not able to compile a simple test program.
Before i was using ndkVersion "22.0.7026061" then change to thisndkVersion "21.1.6352462" and IT WORKED.
I think this is NDK problem and most of answer are outdated try this i hope this will HELP.
If using CMake GUI, you can add a boolean entry named
CMAKE_CXX_COMPILER_FORCED
then set it to True.
This will skip checking process for this build.
Ran into the same problem while re-compiling a project. Turned out that the compiler had been updated in the meantime.
After removing the build directory and creating it again, the compilation completed without errors.

Yocto meta-toolchain fatal error: stdio.h: No such file or directory

Question: How to add the standard library to arm-fslc-linux-gnueabi-gcc
Background:
I just had bitbake compile the meta-toolchain in the Yocto project.
I then installed the resulting SDK-toolchain
$
./build/tmp/deploy/sdk/fslc-framebuffer-glibc-x86_64-meta-toolchain-armv7at2hf-neon-toolchain-2.4.2.sh
which then installed the SDK-toolchain in /opt/fslc-framebuffer/2.4.2/
I can then easily run the executable to source the correct environment variables.
$
./opt/fslc-framebuffer/2.4.2/environment-setup-armv7at2hf-neon-fslc-linux-gnueabi
I now have access to the cross-compiler arm-fslc-linux-gnueabi-gcc
So far so good...
I then downloaded the barebone SDK from NXP here.
It's a great piece of work, but it might be somewhat outdated. First unzip the file, and then follow steps within the SDK readme.pdf.
Following the readme.pdf i do the following: To build the SDK, use the ./tools/build_sdk command from the root folder. I get multiple error but they are all related to the standard library such as:
iMX6_Platform_SDK/sdk/drivers/accelerometer/src/mma8451.c:31:10: fatal error: string.h: No such file or directory #include <string.h>
iMX6_Platform_SDK/sdk/include/sdk.h:40:10: fatal error: stdio.h: No such file or directory #include <stdio.h>
So how do I solve this? Do I cross compile the standard library or do I get the binary some other place?
SDK build by yocto is little bit different than normal arm toolchain.
I believe you used
arm-fslc-linux-gnueabi-gcc hello.c
but actually you need to use Makefiles or Macros like below,
${CC} hello.c -o hello
Write this directly into your terminal or put it into a makefile.

gfortran can't find OpenMP library (omp_lib.mod) under MinGW

I'm trying to compile a Fortran code that someone has sent me. It compiles fine on my Linux box, now I'm trying to compile it under MinGW on Windows. But when I run the gfortran command to compile and link it, it fails with the following error:
undumag_main_omp.f:8175:9:
use omp_lib
1
Fatal Error: Can't open module file 'omp_lib.mod' for reading at (1): No such file or directory
compilation terminated.
I'm using the -fopenmp switch to use OpenMP.
I've installed MinGW (5.3.0) using the Installation Manager, selecting the mingw32-base and mingw32-gcc-fortran packages. Are there other packages I should install for OpenMP compatibility? Or do I need to compile the omp_lib.mod file myself, and if so how? I can see that I have some libgomp.* files in my MinGW\lib\gcc\mingw32\5.3.0 folder, but there is no omp_lib_mod file anywhere.

yocto built tool chain search path issue

I have built images for IMX6 using two different yocto versions. Following are the details.
Yocto Version1:
#curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
#repo init -u git://git.freescale.com/imx/fsl-arm-yocto-bsp.git -b imx-3.10.53-1.1.0_ga
#repo sync
#bitbake core-image-minimal
Yocto Version2:
#curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
#repo init -u git://git.freescale.com/imx/fsl-arm-yocto-bsp.git -b imx-3.14.52-1.1.0_ga
#repo sync
#bitbake core-image-minimal
Tool chain tree structure for both versions of yocto update # http://pastebin.com/Jx7HtANR
I have compiled following sample program using both tool chains built using two different yocto versions.
#include <stdio.h>
int main(void)
{
return 0;
}
But tool chain built using yocto version 2 is giving following error.
test.c:1:19: fatal error: stdio.h: No such file or directory
#include <stdio.h>
^
compilation terminated.
Tool chain built using yocto version 1 is searching for header files under
"build/tmp/sysroots/imx6qsabresd/usr/include", but tool chain built using yocto version 2 is not searching for header files under "build/tmp/sysroots/imx6qsabresd/usr/include", so it is giving error.
Can you help, why tool chain built using yocto version 2 is not searching for header files under "build/tmp/sysroots/imx6qsabresd/usr/include".
Where to change the tool chain configuration in yocto to include the above mentioned search path.
In newer versions, OpenEmbedded based build systems, poisons the built in sysroot definition in the generated cross-compiler. The reason is that we'd like to detect applications that aren't respecting the the cross-compiling environment.
The solution is to not use ${CROSS_COMPILE}-gcc directly, but instead use $CC. $CC, when set by the environment setup script from the generated SDK, will add the correct sysroot argument.

Unable to build Boost libraries with GCC

I am using Windows 7 64-bit, and want to compile the non-precompiled libraries (specifically, I need Filesystem) from the command line (I do not use MSVC). I have MinGW, but read on the Boost website that MSYS shell is not supported, so I'm trying to compile the libraries from the Windows command prompt.
First of all, running bootstrap.bat results in the following error:
Building Boost.Jam build engine
'cl' is not recognized as an internal or external command,
operable program or batch file.
Failed to build Boost.Jam build engine.
Please consult bjam.log for furter diagnostics.
You can try to obtain a prebuilt binary from
http://sf.net/project/showfiles.php?group_id=7586&package_id=72941
Also, you can file an issue at http://svn.boost.org
Please attach bjam.log in that case.
Plus, there is not bjam.log file anywhere in the boost_root directory.
Disregarding this error, and trying to run the downloaded bjam.exe file, I get another error:
c:/boost_1_45_0/tools/build/v2/build\configure.jam:145: in builds-raw
*** argument error
* rule UPDATE_NOW ( targets * : log ? : ignore-minus-n ? )
* called with: ( <pbin.v2\libs\regex\build\gcc-mingw-4.5.2\debug\address-model64\architecture-x86>has_icu.exe : : ignore-minus-n : ignore-minus-q )
* extra argument ignore-minus-q
(builtin):see definition of rule 'UPDATE_NOW' being called
c:/boost_1_45_0/tools/build/v2/build\configure.jam:179: in configu
re.builds
c:/boost_1_45_0/tools/build/v2/build\configure.jam:216: in object(
check-target-builds-worker)#409.check
etc. with quite a lot of complaints. Setting the 'architecture' and 'address-model' options doesn't help.
Any suggestions?
#Andre
Following Andre's suggestion, I created minGW-bjam that was running for an hour and a half and built most of the libraries, but not the one I need at this moment: Filesystem.
Trying to compile only Filesystem, specifying version 2 with define="BOOST_FILESYSTEM_VERSION=2" and --disable-filesystem3 does not help. I get the following error:
gcc.compile.c++ bin.v2\libs\filesystem\build\gcc-mingw-4.5.2\debug\v3\src\operations.o
In file included from ./boost/filesystem/v3/operations.hpp:24:0,
from libs\filesystem\v3\src\operations.cpp:48:
./boost/filesystem/v3/config.hpp:16:5: error: #error Compiling Filesystem version 3
file with BOOST_FILESYSTEM_VERSION defined != 3
libs\filesystem\v3\src\operations.cpp:647:26: warning:
'<unnamed>::create_symbolic_link_api' defined but not used
"g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -DBOOST_ALL_NO_LIB=1 -
DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_FILESYSTEM_VERSION=2 -DBOOST_SYSTEM_DYN_LINK=1 -
I"." -c -o "bin.v2\libs\filesystem\build\gcc-mingw-4.5.2\debug\v3\src\operations.o"
"libs\filesystem\v3\src\operations.cpp"
etc. with a lot of ...failed statements.
Any hints here?
It's easy. Just use "bootstrap.bat gcc" to select GCC
The bootstrap script assumes the msvc compiler is available. But you can build bjam by hand without the bootstrap script:
Step into the tools\build\v2\engine\src directory and call "build.bat mingw". It will create a bjam.exe. You can then put it in your %PATH% or perhaps in the root boost directory...
To be honest, I usually build bjam like this with the msvc compiler and use this "msvc-bjam" to build my mingw boost libraries.
So... the first part of the problem was solved by Andre's suggestion.
The second part was solved by setting the variable BOOST_FILESYSTEM_VERSION to 3 everywhere (the error above complains about incompatibility with what is set in file user.hpp). Although this is not the default option for Boost 1.45 that I'm using, it's the only thing that works (i.e. bjam wants to compile version 3 no matter what). So now I have version 3 of the filesystem library, and version 2 for all others, but that doesn't seem to be an issue for the moment.
I do have a problem with using Boost with OpenCV and Eigen libraries, though... off to the next challenge ;)
Since I can't comment yet, I want to add that I ran
bootstrap mingw
to generate b2 properly and then
b2 --build-dir="c:\boost_release" toolset=gcc --build-type=complete "c:\boost_release\stage"
The includes will be located at your boost root folder (boost_1_58_00/boost) and your binaries at the specified build folder.

Resources