header includes in cross-compile environment escape to /usr/include

header includes in cross-compile environment escape to /usr/include

Imagen de David G.

Environment: Linux (Ubuntu 12.04), ICC (version XE 13.0), cross-building for Wind River Linux When we use the Wind-River-provided gcc in the Wind-River SDK, header includes start with our headers, move to the headers in the SDK sysroots (there are two) and stay there. When we use ICC, header includes start with our headers, move to the headers in the first SDK sysroot, and then escape to /usr/include. For example, one of our library files is compiled: icc -c -fno-omit-frame-pointer -w3 -Wall -diag-disable 274 -Wno-attributes -xAVX -platform=wrl50 -pthread -shared -fpic -O2 \ -MD DXM_Lib.c -o cpu/DXM_Lib.o And the generated dependency file starts with: cpu/DXM_Lib.o: DXM_Lib.c ../../../../Include/PTL_Lib.h \ ../../../../Include/PTL_Types.h ../../../../../Include/stdints.h \ /home/WindRiver/SDK/sysroots/x86_64-wrlinuxsdk-linux/usr/toolchain/bin/../lib/gcc/i686-wrs-linux-gnu/4.6.3/include/stdint.h \ /usr/include/stdint.h \ /usr/include/features.h \ /usr/include/bits/predefs.h \ /usr/include/sys/cdefs.h \ /usr/include/bits/wordsize.h \ /usr/include/gnu/stubs.h \ /usr/include/bits/wordsize.h \ /usr/include/gnu/stubs-64.h \ /usr/include/bits/wchar.h \ /usr/include/bits/wordsize.h \ It appears the -platform=wrl50 gets us the path to the first sysroot, but not to the second? For comparison, a cross-GCC dependency file starts: cpu/DCP_Lib.o: DCP_Lib.c ../../../Include/DCP_Lib.h \ ../../../Include/PTL_Lib.h ../../../Include/PTL_Types.h \ ../../../../Include/stdints.h \ /home/WindRiver/SDK/sysroots/x86_64-wrlinuxsdk-linux/usr/toolchain/bin/../lib/gcc/i686-wrs-linux-gnu/4.6.3/include/stdint.h \ /home/WindRiver/SDK/sysroots/intel_xeon_core-wrs-linux/usr/include/stdint.h \ /home/WindRiver/SDK/sysroots/intel_xeon_core-wrs-linux/usr/include/features.h \ /home/WindRiver/SDK/sysroots/intel_xeon_core-wrs-linux/usr/include/bits/predefs.h \ /home/WindRiver/SDK/sysroots/intel_xeon_core-wrs-linux/usr/include/sys/cdefs.h \ /home/WindRiver/SDK/sysroots/intel_xeon_core-wrs-linux/usr/include/bits/wordsize.h \ /home/WindRiver/SDK/sysroots/intel_xeon_core-wrs-linux/usr/include/gnu/stubs.h \ /home/WindRiver/SDK/sysroots/intel_xeon_core-wrs-linux/usr/include/gnu/stubs-64.h \ /home/WindRiver/SDK/sysroots/intel_xeon_core-wrs-linux/usr/include/bits/wchar.h \

publicaciones de 6 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.
Imagen de yang-wang (Intel)

Hi David,
     Could you please let me know your icc version? Are you using icc compiler from Intel System Studio for Linux?  Please note that the classic Intel Composer XE does not formally support the cross build for windriver linux target. We need use the compiler from Intel System Studio for linux which provide the formally cross-build support for Windriver Linux target. For details of Intel System Studio for Linux, please refer to http://software.intel.com/en-us/intel-system-studio

thanks.

-Yang

 

Imagen de David G.

We are using ICC from Intel Composer 2013.3.163: icc -v reports 13.1.1 (gcc 4.6.0 compatability).  We should be updating to SP1 shortly.

We know about Intel System Studio, but we already had a bunch of licenses for Composer, and the Wind River support line gave us a wrl50.env script to apply to our Composer installation.  The missing step (that fixed the headers escaping) was setting the two variables WRL_TOOLCHAIN and WRL_SYSROOT in our environment.

Imagen de yang-wang (Intel)

Hi David,
     Could you please check your environment variable WRL_TOOLCHAIN and WRL_SYSROOT is set correctly? I tried a simple test case with composer 2013.3.163 and I can see the headers are included correctly. These header files should come from $WRL_SYSROOT/usr/include. For your example, the WRL_SYSROOT should be export to /home/WindRiver/SDK/sysroots/intel_xeon_core-wrs-linux (export WRL_SYSROOT=/home/WindRiver/SDK/sysroots/intel_xeon_core-wrs-linux).  In addition, the WRL_TOOLCHAIN should also be set correctly. Use command "$cd $WRL_TOOLCHAIN/bin", you should enter the folder where the windriver gcc compiler(i686-wrs-linux-gnu-gcc) is located.

If this issue still exists, could you please attach a simple reproducor? A sample c file which can reproduce the issue would be great for me to investigate the issue.

Thank you.

-Yang

 

Imagen de David G.

That's what my previous comment (on 10/11) said.  We weren't setting WRL_TOOLCHAIN or WRL_SYSROOT <b>at all</b>.  Once I changed our environment script to set them, the problem went away.

Imagen de yang-wang (Intel)

Hi David,

      Thanks for update. Glad to see the issue was resolved. Yes, the two environments are necessary for cross build. They are used in the wrl50.env file by icc compiler. You may refer to http://software.intel.com/en-us/articles/using-intel-c-compiler-for-embedded-system for more details.

thanks.

-Yang

Inicie sesión para dejar un comentario.