- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In the Intel System Studio document, "Using Intel C++ Compiler for Embedded System", on page 2, it is stated that the SDK and SYSROOT must be built. We have been building our app (targeting WR Linux 4.3 on E6xx Atom) using gcc, with no reference to a sysroot. We are using a vendor provided kernel.
I do not fully understand what the connection to sysroot is (only what is stated in the above doc, i.e., it is a folder that contains glibc and header files) - for what, I would like to ask???
Do I need to build a sysroot to use the Intel compiler regardless of using a pre-built kernel? If so, why is it necessary when it is not being used in our gcc builds?
Thank you.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Eric,
How do you build your own application for Windriver4.3 target? Are you using cross-build with SDK from Windriver? When you build your application using gcc compiler for Windriver Linux4.3, do you have an option --sysroot=xxx to specify the sysroot of your target? Normally you can find this option from your Makefile. You may change WRL_SYSROOT to the same path as --sysroot option. SYSROOT is the path to specify the target glibc header files and libraries. When we do the cross build, we should use the headers and libraries from the target system. Normally it is in a specific folder on your host system. When the SYSROOT is specified, the compiler will use the headers and libraries from target sysroot instead of your host default (/usr/include, /usr/lib etc).
Thanks.
-Yang
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There is a heirarchy of make files that builds the design, using GNU gcc, within Fedora Linux 14.
There is no reference to SYSROOT or anything else tied to the WR Linux.
Two of the output files from the build process, ptl_main and a corresponding deamon file are then copied over to the /opt/proj folder on the target system (WR Linux 4.3) and run from there.
I don't have a handle yet on how the cross-compile is set up to use the proper WR libraries/headers.
So far, it looks like there isn't any tie-in with WR.
When I figure that out, will let you know.
Meanwhile, if anything above tells you what might be going on, please let me know.
Thank you again for your time.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Eric,
does this imply that the GCC you are curently using is the standard Fedora 14 gcc in /usr/bin/ etc. instead of a WR Linux specific GCC?
This is possible, but there is a significant risk of not all library and shared object dependencies not being resolved correctly, which is whay that would gnerally not be a recommended approach.
Anyway, we can chat more about this and see if using a regular native GCC is indeed sufficient in your case.
Thanks, Rob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I spoke with the SW engineer who created the design:
What we are doing is not true cross-compiling. Typically when cross-compiling, one is trying to create an executable to run on a different type of processor (like creating an executable for an ARM processor on a platform using an intel x86 processor).
However, we are compiling for an x86 type cpu (Atom E6xx) on an x86 cpu (host PC running Fedora 14 Linux).
We set the optimization flags (OPTIMIZATION_FLAGS= -O2 -march=atom -m32) on the build (via Makefile) to target the Intel ATOM processor, but it doesn’t require any special headers from WR.
(We are using the standard Fedora 14 gcc)
So, based on this premis, I would ignor the SYSROOT settings, and just change all the gcc's in our make files, to icc, as I did for the static analysis.Then rebuild the design and download to the target, correct?
If there is risk in this approach, would appreciate some insights into the nature of these risks?
Thank you again.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Eric,
for self-contained applications without much system dependencies you are probably ok.
The risk is that you are not using the same GCC that is being used to build WR Linux itself. Thus if there are version differences in the C/C++ libraries and headers you may pull in library function and definitions that do not exactly match to what is found on the target.
The more C++ you use and/or the closer your code is to the system software level the bigger the risk.
Thanks, Rob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Eric,
If you are using Fedora host gcc compiler for your compilation, you can use icc directly without SYSROOT. In this case, the icc compiler will find the "gcc" binary from PATH environment and use the same include/libraries on host system as gcc compiler. You don't need the option -platform=<val> and you don't need to set the SYSROOT and TOOLCHAIN environment variable.
As Rob mentioned, since your target is windriver linux but your host is Fedora. Most likely your application compiled by host gcc can work on target but there is the risks.
For more information on how to port your application build from gcc to icc, you can refer to http://software.intel.com/en-us/articles/using-intel-c-compiler-for-embedded-system#porting . Mostlikely you just need to change the compiler name in your Makefile to make it work.
thanks.
-Yang

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page