Clang Cross Compiler - I'm almost there!

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 :slight_smile:

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 :slight_smile:

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?)
  * Clang looks in non 'usr' paths based on <sysroot>

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

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 :slight_smile:

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 :slight_smile:

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.)

This is a somewhat messy area, because the GNU toolchain uses two
different meanings for the term sysroot. The first one is what is used
by clang too. Here, sysroot references essentially an installed staging
area like you would use e.g. with Linux and could chroot into. All
search paths get prefixed by <sysroot>, except the toolchain specific
directories themselve. The second meaning in the GNU toolchain is to
refer to a directory under the tool install prefix. I don't think we
implement that ATM. I had no interest in that as it doesn't cover the
cross-compiling cases I am interested in.

Joerg

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.)

Done: http://llvm.org/bugs/show_bug.cgi?id=13611 with your @gmail.com on the cc list, as bugzilla suggested.

The “find” attachment is unpruned, as there is nothing in there except headers, libs and the underlying bins.

Thanks!

  • DavidM