Supporting multiple targets from a single 'clang' installation

Clang Frontend
1

Hi CFE-Dev,

I am starting to get adventurous, and would like to build our out-of-tree version of CLang so that it can target both our SHAVE CPU as a cross-compiler, and the X86 host. I have no problem getting this to build and generate code, but where I am running into trouble is in the configuration of where the headers and libraries should reside.

How should I go about configuring the CLang build so that I can have it locate the system headers and libraries corresponding to each target?

Thanks,

MartinO

2

You can use --sysroot= to specify the path for headers and libraries and -B to specify the path for tools (e.g. linker and assembler). There is currently no way of having a single clang symlink the has a custom -target, --sysroot, and -B, though there was some discussion recently of providing config files that do this.

David

3

For our out-of-tree madness (which I'll push a bunch of patches public
very soon) we do the following

4

Hi Martin,

This is a common problem, with multiple solutions. The easiest one is
to use triples.

Clang recognises default locations from distributions (Linux, BSD,
Darwin, Windows), so if you set the triple correctly, and you have a
sysroot with that triple in the right place (tm), everything works
auto-magically.

Reality is, of course, never that glamorous.

As others have said, you'll find that your sysroot format is not the
same as the driver expects, or that not all the libraries will be
found in the right place and you'll end up needing additional compiler
flags, which don't work out of the box.

So, the main alternatives are:

1. Distribute your sysroot in a way that Clang understands without
glitches (this may involve moving unrelated libraries and headers
together).
1.1 Then ask people to use "clang --target=foo-bar"
1.2 Or create symlinks "foo-bar-clang" to "clang" (same effect)

2. Create wrapper scripts "foo-bar-clang" that will call clang with
the right target/sysroot/B/L/I flags (no need to break your sysroot
apart).

Long term, we're discussing other usages of configuration files, or
reusing the existing mechanisms in a better way. But you'll probably
release your toolchain before that.

cheers,
--renato

5

Thanks for the responses on this, and sorry for the delay getting back to you.

If I use the ‘TLD/{VERSION}/lib|include/{PLATFORM}/{TARGET}/{BITS}/’ approach, it will mean altering the default for the X86 target, but it would be quite workable. Yes, I remember the discussion about the configuration files, and as I am only beginning to experiment with this, I can easily hold off until the configuration file discussion is decided and then plan how to tackle this.

All the best,

MartinO