[cfe-dev] Clang Cross Compiler - I'm almost there!

[Chandler Carruth]

On Wed, Aug 15, 2012 at 1:26 AM, David Mirabito <david.mirabito at gmail.com>wrote:

> Hello List,
>
> I know there's been much conversations about Clang and building for ARM
> recently, and as far as I can tell I won't be repeating anything already on
> the list. I'm really close now :)
>
> So I am interested in using Clang to build for our own RTOS-like
> environment where today we use an arm-none-eabi-* toolchain from
> codesourcery/mentor. My understanding is that this comes with a generic
> newlib implementation (hence 'none' in the triple), which boils down to a
> few fundamental functions (sbrk, write, exit, ...) which are implemented in
> a os-specific lib which is pulled in to all apps via the LD script. This
> works just fine.
>
> So I placed a symlink in
>         /home/davidm/bin/arm-2009q/bin/arm-none-eabi-clang
> (next to arm-none-eabi-gcc & co.) pointing to
>         /home/davidm/myinstall/bin/clang
> and set up my PATH appropriately.
>
> (I've unpacked the codesourcery tarball into ~/bin, hence the two bins in
> the toolchain path)
>
> This kind of works, in that I can build ARM ELFs for the OS which work
> just by replacing gcc with clang in one appropriately prefix'd place in my
> makefile
>
> However some corner cases (like using assert()) indicated that incorrect
> headers were being pulled in, and it just so happened that my linux system
> headers matched the newlib definitions well enough (for the simple uses in
> my codebase) that there were no [obvious] issues. Assert.h breaks this, and
> honestly I'm surprised it got as far as it did :)
>
> So I experimented with -sysroot and strace'd some invocations. With
> --sysroot, it seems that arm-none-eabi-clang always looks in
>  <sysroot>/usr/include and <sysroot>/usr/local/include for the headers and
> then barfs when stdio.h is not found.
>
> For me, it seems clang should be looking at
>  /home/davidm/bin/arm-2009q/arm-none-eabi/include/stdio.h, i.e:
>         $ arm-none-eabi-gcc -print-sysroot
>         /home/davidm/bin/arm-2009q/bin/../arm-none-eabi
>
> So I see two potential solutions:
>         * Clang  knows to look in
> <compiler_invocation_path>/../<triple>/include  (is this a standard
> location, or a codesourery piece of magic?)
>

Just so you understand, there is no standard. I've been slowly building up
the header search logic bit by bit by observing what Linux systems have in
the wild, and what GCC does on those Linux systems. I think the
codesourcery toolchain is just as reasonable of a pattern to support in
Clang as a Linux distro.


>         * Clang looks in non 'usr' paths based on <sysroot>
>

This is definitely reasonable, it's just that we've not taught it about
these *specific* path structures.

What would help me support this cross compile use case is to understand the
complete sysroot structure you would like Clang to work with. Can you file
a bug, CC me, and attach a 'find -type f' output of the sysroot you want to
compile within? (potentially pruning out all the completely irrelevant
stuff like 3rd party software, man pages, etc... mostly interested in
binaries, libc, libstdc++, header files, etc.)


>
> Could/should Clang be doing something like this, or am I misconfigured?
>
> If not, I could probably kludge various Makefiles with -isysroot, -I and
> friends to make it work,  but it wouldn't be ideal. (drop-in replacements
> ease adoption).
>
> This is with SVN tip, as of yesterday - configured, built (make) and
> installed with nothing special (other than setting release+asserts,
> c,c++,obj-c only, and the install prefix)
>
> Thanks,
> David M
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120815/7acaf2e2/attachment.html>