topic Re: Is arm-poky-linux-gnueabi-gcc for iMX6 SoloX buggy ? in i.MX Processors

Is arm-poky-linux-gnueabi-gcc for iMX6 SoloX buggy ?

ag74 — Mon, 07 Sep 2015 15:27:00 GMT

Hello,

I'm in charge of evaluating the iMX6 SoloX CPU using the iMX6SX Sabre SD demo board.

I succeeded in compiling the rootfs and the meta toolchain using Yocto but now I'm facing an issue with arm-poky-linux-gnueabi-gcc.

I'm able to compile some GPU samples but I can't run them on the demo board, linux tells me "no such file or directory".

I checked the header section with readelf and everything seems to be ok (if I compare it with the /sbin/ifconfig header section).

To figure out why I can compile an ELF file but I can't execute it, I created a simple hello world sample.

If I compile using the following commands everything's ok and I can run the output file (hello).

arm-poky-linux-gnueabi-gcc -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 --sysroot=/opt/freescale/poky/1.7/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi -o hello hello.c

But if I compile the same source file in several stages (as It's done in makefiles).

Frist I create a .o file and then I create the ELF file, I can't execute the output file (hello_bin).

Here's the command I use to generate the .o file.

arm-poky-linux-gnueabi-gcc -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 --sysroot=/opt/freescale/poky/1.7/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi -c hello.c -o hello_bis.o

and the command to generate the ELF file.

arm-poky-linux-gnueabi-gcc --sysroot=/opt/freescale/poky/1.7/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi -o hello_bis hello_bis.o

I can execute hello but not hello_bis. The files do not have the same size.

I tried to repeat those two tests using arm-linux-gnueabihf-gcc, which is the gcc from the iMX6-based Toradex module, and the sysroot generated by freescale Yocto.

With this configuration (Toradex's gcc + freescale's sysroot) I can compile hello and hello_bis, they have the same size and they both work fine on the demo board.

After that I tried to recompile one of our biggest app using its makefile. I can't run the output generated by the arm-poky-linux-gnueabi-gcc but I can run the one generated by arm-linux-gnueabihf-gcc.

Is arm-poky-linux-gnueabi-gcc buggy ?

Does anyone can explain why the hello binary generated in one stage works fine and the hello_bis binary generated in two stages does not when using arm-poky-linux-gnueabi-gcc but they both work fine when generated with arm-linux-gnueabihf-gcc using the same compiling flags ?

Re: Is arm-poky-linux-gnueabi-gcc for iMX6 SoloX buggy ?

dhavalvadhar — Tue, 08 Sep 2015 04:47:22 GMT

Hi Ag74,

We are facing same issue. It would be great if you can share the link to download the toolchain 'arm-linux-gnueabihf-gcc', the one you were talking about in your post.

Thanks,

Dhaval

Re: Is arm-poky-linux-gnueabi-gcc for iMX6 SoloX buggy ?

BiyongSUN — Tue, 08 Sep 2015 06:02:19 GMT

Please follow the Yocto development flow call SDK, which is populated from yocto build system for application develop.

bitbake <image> -c populate_sdk

here is the example, of course SDK installed:

source /opt/poky/1.6.2/environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabi

$CC -o hello hello.c

And the all the development should based on the SDK including the rootfs, library, etc.

Please check the Yocto website and document for more details.

For why can not execute the hello in different toolchain. That is basic knowledge for a software engineer and long topic.

It is related execute loader for different toolchain and library, which is for rootfs.

For example, if you use dynamic link with uclibc then can not execute in the glibc rootfs system, which need loader and match the link and execute relocation.

But it you make a static link with uclibc, It can run in the glibc system. cause it no need loader.

A static link hello. also can run in the android, which is bionic gcc and lib.

You can try link with flag -static to try to see what happens.

Re: Is arm-poky-linux-gnueabi-gcc for iMX6 SoloX buggy ?

ag74 — Tue, 08 Sep 2015 08:09:46 GMT

Thanks for this reminder but this is not the cause of the issue.

I figured out what's wrong with arm-poky-linux-gnueabi-gcc.

Here's the correct command line to link the ELF file.

arm-poky-linux-gnueabi-gcc -mfloat-abi=hard --sysroot=/opt/freescale/poky/1.7/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi -o hello_bis hello_bis.o

I added the float flag to the link command and now it works fine. The two different ELF files have the same sizes and both work fine.

Poky may not be built with hard floats by default.

Re: Is arm-poky-linux-gnueabi-gcc for iMX6 SoloX buggy ?

ag74 — Tue, 08 Sep 2015 08:16:19 GMT

Hi Dhaval Vadhar,

I figured out what's wrong see my latest post and add the flag -mfloat-abi=hard to your linking command it may fix your issue too.

Re: Is arm-poky-linux-gnueabi-gcc for iMX6 SoloX buggy ?

dhavalvadhar — Tue, 08 Sep 2015 10:03:45 GMT

Thanks ag74 for your reply. Let me check at our end.

Re: Is arm-poky-linux-gnueabi-gcc for iMX6 SoloX buggy ?

bhayani_sunny — Wed, 09 Sep 2015 07:09:40 GMT

Hi Ag74,

I am using the below compiler flags which are having the same compiler switches as you have mentinoed:

-Wall -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 --sysroot=/opt/poky/1.7/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi

but I am getting the below error:

-sh: ./testApp: No such file or directory

The testApp is a 3rd party application. It uses lib-pthread.

The path for dynamic linking is taken from /opt/poky/1.7/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/lib

Can you please let me know if I need to check anything else.

Thanks,
Sunny

Re: Is arm-poky-linux-gnueabi-gcc for iMX6 SoloX buggy ?

ag74 — Wed, 09 Sep 2015 07:23:44 GMT

Hi Sunny Bhayani,

I am using the below compiler flags which are having the same compiler switches as you have mentinoed:
-Wall -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 --sysroot=/opt/poky/1.7/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi

The switches above are the ones used for the compiling stage.

The switches used during the linking stage may look like something similar to the ones below:

-lpthread -mfloat-abi=hard --sysroot=/opt/poky/1.7/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi

If you use OpenVG and ELG libs you must add -lOpenVG -lEGL.

If you use math functions you must add -lm.

If the app is coded in C++ and compiling with GCC you must use -lstdc++.

If it still does not work, can you post the make's output ?

Re: Is arm-poky-linux-gnueabi-gcc for iMX6 SoloX buggy ?

bhayani_sunny — Wed, 09 Sep 2015 08:07:08 GMT

Hi Ag74,

Thanks a lot for the info.

You correctly pointed. I was adding the switches to compilation.

Now I have added the 2 flags that you mentioned whiling linking and the problem is resolved.

Thanks for the help.

Thanks,
Sunny

Re: Is arm-poky-linux-gnueabi-gcc for iMX6 SoloX buggy ?

Yuri — Thu, 10 Sep 2015 09:09:26 GMT

Hi,

As for floating point support – FSL i.MX6 BSPs do not have it under LTIB release
and does support for Yocto. Say, for the recent L3.14.28 :

“Supports the GCC 4.9.1 toolchain with the hardware floating point build”.

"About compiler options when using NEON in i.MX6DL"

https://community.freescale.com/thread/331886

Regards,

Yuri.

Re: Is arm-poky-linux-gnueabi-gcc for iMX6 SoloX buggy ?

yooliang — Tue, 17 May 2016 06:15:15 GMT

Hi ag74

Some problems and error I need your help:

y@lxy-Latitude-3540:~/opencv-camera-test---i.MX6-Yocto/src$ /opt/fsl-imx-fb/3.14.52-1.1.0/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 --sysroot=/opt/fsl-imx-fb/3.14.52-1.1.0/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi -g -O0 -o readpicture readpicture.cpp `pkg-config --cflags --libs opencv`

/opt/fsl-imx-fb/3.14.52-1.1.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.2/ld: cannot find -lopencv_ts

collect2: error: ld returned 1 exit status