Re: Building clang with Yocto

Jim Rafert <jimr@...>

Hi Chan,

The errors that you are experiencing point to a mismatch between the target architecture of the compiler, and the headers and libraries that the compiler finds. There are several steps that are necessary to get right before you can produce correct code with the compiler.

1. Configure the clang compiler build such that the compiler will be built to execute on the architecture of the workstation you that you intend to use to compile code for your target with clang.

2. Configure the clang compiler build such that the clang compiler will support code generation for the architecture of the target machine.

3. Modify a copy of the environment-setup file in /opt/poky/... to
Here's a page which explains cross compilation using clang.

Here's an excerpt that talks about specifying the target triple which defines the target architecture that the clang compiler will produce code for:

Target Triple

The basic option is to define the target architecture. For that, use -target <triple>. If you don’t specify the target, CPU names won’t match (since Clang assumes the host triple), and the compilation will go ahead, creating code for the host platform, which will break later on when assembling or linking.

The triple has the general format <arch><sub>-<vendor>-<sys>-<abi>, where:
arch = x86, arm, thumb, mips, etc.
sub = for ex. on ARM: v5, v6m, v7a, v7m, etc.
vendor = pc, apple, nvidia, ibm, etc.
sys = none, linux, win32, darwin, cuda, etc.
abi = eabi, gnu, android, macho, elf, etc.
The sub-architecture options are available for their own architectures, of course, so “x86v7a” doesn’t make sense. The vendor needs to be specified only if there’s a relevant change, for instance between PC and Apple. Most of the time it can be omitted (and Unknown) will be assumed, which sets the defaults for the specified architecture. The system name is generally the OS (linux, darwin), but could be special like the bare-metal “none”.

When a parameter is not important, they can be omitted, or you can choose unknown and the defaults will be used. If you choose a parameter that Clang doesn’t know, like blerg, it’ll ignore and assume unknown, which is not always desired, so be careful.

Finally, the ABI option is something that will pick default CPU/FPU, define the specific behaviour of your code (PCS, extensions), and also choose the correct library calls, etc.

I hope that you find this helpful.

From: Yu, Chan KitX [chan.kitx.yu@...]
Sent: Tuesday, December 23, 2014 1:21 AM
To: Paul Eggleton
Cc: Jim Rafert; yocto@...
Subject: Re: [yocto] Building clang with Yocto

I tried ldd-ing my binary on my build machine since it doesn't work on my image and it was built on glibc indeed. Since yocto is based on ulibc so it won't work even my target platform is roughly the same as my build platform. I wonder what options should I specify to get llvm to build against the Yocto's libraries rather than my build machine's.

As I said in IRC yesterday I found which should suit my needs but I get stupid errors on uint32_t:

-3.3.src/include/llvm/Support/BranchProbability.h:27:3: error: 'uint32_t' does not name a type
uint32_t N;

I tried adding #include <cstdint> to that header but no luck.

-----Original Message-----
From: Paul Eggleton [mailto:paul.eggleton@...]
Sent: Monday, December 22, 2014 7:22 PM
To: Yu, Chan KitX
Cc: 'Liviu Gheorghisan'; 'Jim Rafert'; yocto@...
Subject: Re: [yocto] Building clang with Yocto

Hi Chan Kit,

On Monday 22 December 2014 03:33:17 Yu, Chan KitX wrote:
Here's an update FYI. I have managed to get clang sort of working. It
compiles my sample code but I can't get the binary to execute. ./a.out
simply returns:

./a.out: No such file or directory.

I'm sure that a.out exists and weirdly I could get the same binary
file to run on my build machine. So I guess it could be because of
some architecture difference but both target and build platform are
quite the same (Intel x64 in build machine and BayleyBay for target
platform) I used
valleyisland-64 for the target platform so both should be able to
64 bit binaries. I suppose I can specify some other configuration
options there but I have no idea what to specify the configure
parameter --target=<TARGET> . x64 did not do any good. So any idea?
That sounds a bit like the binary has been linked to libraries in the host libdir rather than the correct one for the target. You may be able to verify that using ldd.



Paul Eggleton
Intel Open Source Technology Centre

Join to automatically receive all group messages.