[cfe-dev] Cross compiling with clang (and sysroot support)
steveire at gmail.com
Sat May 18 02:34:59 PDT 2013
Joerg Sonnenberger wrote:
> On Fri, May 17, 2013 at 05:05:24PM +0200, Stephen Kelly wrote:
>> However, there's still a problem. It seems that the term 'sysroot' means
>> different things to clang and gcc.
> Clang uses it to specify a system root. Basically, prepare a directory
> you would be able to chroot it into.
Clang sees only one 'root'. GCC sees two. One is for the toolchain (which
does not get deployed to the target) and one is for the rootfs (which does
get deployed to the target). Typically I get both separately from a customer
and use them in the way I've been describing here. The customer typically
gets the toolchain from a third party. The rootfs is either made by the
customer or also comes from a different third party.
I think you are suggesting that I copy files around from the toolchain to
the rootfs, and use that as the sysroot? I find the suggestion to do that
without tracking, without versioning and without conspiring with upstreams
odd. It seems like a very bad idea. Have I understood you correctly?
Does anyone else on this list agree that copying files around is the way
cross compiling should work with clang?
> The GNU toolchain is pretty
> inconsistent in what it does with the option, so yes, it does mean a
> number of different things.
Please be more specific.
>> If I have to use the sysroot option to tell clang where to find crtX.o
>> files, then I can't use it to tell clang where to find the zlib headers
>> and libraries. They are not in the same location as the crti.o etc.
> No, that should be done with -B.
Your response is ambiguous. What are you saying should be specified with -B?
The location of the crti.o or the sysroot? How does this response relate to
the suggestion to copy files around?
>> Clang also does not search in the arch-specific include dir as gcc does,
>> so it doesn't find sys/types:
>> $ clang -v -target arm-linux-gnueabihf --sysroot
>> rootfs/ -B /usr/arm-linux-gnueabihf/lib/ main.c
>> ignoring nonexistent directory "/usr/bin/../lib/clang/3.2/include"
>> ignoring nonexistent directory "/home/stephen/rpi/rasp-pi-
> This is a bug in the Debian/Ubuntu workaround. It seems to be looking
> for the host triple and not the target triple.
I don't know what the word 'workaround' is supposed to mean in that
sentence, unless it's meant in a derogatory way.
In any case, you're right. I noticed the same but I didn't realize it might
be a distro bug.
More information about the cfe-dev