[PATCH] Support cross-compiling for Arm on a x86 Linux machine

[Murali, Sriram]

Hi Simon,
Can you please have one more look at the patch ? I added a test to check for cross-compiler include directories.

Cheers
Sriram


-----Original Message-----
From: Sriram Murali [mailto:sriram.murali at intel.com] 
Sent: Thursday, October 10, 2013 11:07 AM
To: Murali, Sriram
Cc: amara.emerson at arm.com; renato.golin at linaro.org; simon at atanasyan.com; david.tweed at gmail.com
Subject: Re: [PATCH] Support cross-compiling for Arm on a x86 Linux machine


   I added a test for checking the new version number, but had to add some extra directories in the Input, in order for clang to detect it. Please let me know if there is a better way to add tests. I am a novice in Clang Driver code.


================
Comment at: lib/Driver/ToolChains.cpp:2607 @@ -2604,1 +2606,3 @@
   }
+
+  if (addLibStdCXXIncludePaths(
----------------
Simon Atanasyan wrote:
> Why has this code been moved here? Is it necessary to do this check at the end?
yes, if i have it before the for loop, it adds the include directory that conflicts with the right one.

bits/c++config.h is *only* found in the second path of these two consecutively added paths
/usr/include/c++/4.8
/usr/arm-linux-gnueabihf/include/c++/4.8.0

The first path is added by below line, and second path is added by the for loop that spans over IncludePathCandidates. If it is add the include paths in this order, iostream header in the first path cannot find bits/c++config.h, and errors out. 

Since I moved the path added using VersionText into the for loop, I had to move this code below the for loop.

================
Comment at: lib/Driver/ToolChains.cpp:2595 @@ -2592,3 +2594,3 @@
     // Android standalone toolchain has C++ headers in yet another place.
-    LibDir.str() + "/../" + TripleStr.str() + "/include/c++/" + Version.Text,
+    LibDir.str() + "/../" + TripleStr.str() + "/include/c++/" + 
+ VersionText,
     // Freescale SDK C++ headers are directly in <sysroot>/usr/include/c++,
----------------
Simon Atanasyan wrote:
> Now we always use three-numbers form **x.y.0** in case of version with no patch number. Is it true for any toolchain? If there is a toolchain which uses two-numbers form **x.y** we cannot find a path. Probably we need to check both variants.
I checked for powerpc, it does put it in x.y.0 path. I am adding a FIXME as a reminder to check for other targets, and added both x.y.0 and x.y include path in that order.

I had to download the package for these targets to verify the install location.
If there is a quick way to check other targets, I will be happy to check them.


http://llvm-reviews.chandlerc.com/D1823