I created the SDK corresponding to my Image using “-c populate_sdk”, and everything went ok.
When I try to use the generated toolchain (which is inside “arm-angstrom-linux-gnueabi” folder, using arm-angstrom-linux-gnueabi-g++ compiler), then I get many error messages about *.h missing. Strange.
Then I downloaded the “gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabihf.tar”, this with hard float support, and everything compiles fine.
So my question is how to create an SDK with hard float support. I think it should be in the DEFAULTTUNE of the MACHINE, but I am not really familiar with it. I see no such variable in my machine *.conf file, so I guess it is inherited from another layer, but which one ? What could I use for an apalis iMX6D 512MB ?
OE moved away from generating different toolchains depending on the calling convention.
angstrom-linux-gnueabi-g++ can generate hard float code but the default setting is not hard float.
You need to add -mfloat-abi=hard when calling the compiler and linker.
Have a look on the environment after you sourced the environment script:
I was able to compile the single .cpp files by replacing the CXX (and use the one from the environment script) inside my makefile.
Then I had an issue with CXXFLAGS. Inside my original makefile I am using CXXFLAGS = -Wall -O2 -static.
When using the “gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabihf” I can compile and link my project without changing my original CXXFLAGS, while if I use the Open Embedded SDK, I have to use the same CXXFLAGS as the environment script (CXXFLAGS= -O2 -pipe -g -feliminate-unused-debug-types). My original CXXFLAGS without -static also works (CXXFLAGS = -Wall -O2).
Is there any difference in this respect between the OpenEmbedded SDK (with flags for Hard float) and “gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabihf” ?
Is there any difference in this respect between the OpenEmbedded SDK (with flags for Hard float) and “gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabihf” ?
One difference is that the binary toolchain is packaged with a version of the gcc and libc libraries, both for static and dynamic linking while OE puts those libraries into the target rootfs and by default only installed the shared libraries.
I guess this is also the reason why you see differences. The OE SDK by default do not contain statically linked libraries which results in error messages like the following:
gcc -static -O3 -o prog prog.c
/usr/bin/ld: cannot find -lc
collect2: ld returned 1 exit status
If you really want to link with -static you could add all libraries additionally in their static form to the SDK.
Please have a look at the this post on the yocto mailinglist.
…/sysdeps/arm/start.S:124: error: undefined reference to ‘__libc_start_main’
…
Looking at your suggestion, I tried to add the following:
SDKIMAGE_FEATURES = “dev-pkgs dbg-pkgs staticdev-pkgs”
to my layer image:
…/meta-my-layer/recipes-images/images/my_image.bb
Then I rebuilt my Image: bitbake my-image
Then populated the SDK: bitbake my-image -c populate_sdk
but again I receive the above errors.
Something strange is the fact that I don’t see anything new built with today’s date inside the SDK, especially in the path where it looks for the libraries:
Something strange is the fact that I don’t see anything new built with today’s date inside the SDK, especially in the path where it looks for the libraries.
That is expected. The static libraries have been built alongside the dynamic ones. The difference should be that the packages which contain them should additionally be installed.
Any suggestions on how to debug the problem further ?
