<div class="gmail_extra"><div class="gmail_quote">On Wed, Aug 15, 2012 at 1:26 AM, David Mirabito <span dir="ltr"><<a href="mailto:david.mirabito@gmail.com" target="_blank" class="cremed">david.mirabito@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello List,<br>
<br>
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 :)<br>
<br>
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.<br>

<br>
So I placed a symlink in<br>
        /home/davidm/bin/arm-2009q/bin/arm-none-eabi-clang<br>
(next to arm-none-eabi-gcc & co.) pointing to<br>
        /home/davidm/myinstall/bin/clang<br>
and set up my PATH appropriately.<br>
<br>
(I've unpacked the codesourcery tarball into ~/bin, hence the two bins in the toolchain path)<br>
<br>
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<br>
<br>
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 :)<br>

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

<br>
For me, it seems clang should be looking at  /home/davidm/bin/arm-2009q/arm-none-eabi/include/stdio.h, i.e:<br>
        $ arm-none-eabi-gcc -print-sysroot<br>
        /home/davidm/bin/arm-2009q/bin/../arm-none-eabi<br>
<br>
So I see two potential solutions:<br>
        * Clang  knows to look in <compiler_invocation_path>/../<triple>/include  (is this a standard location, or a codesourery piece of magic?)<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
        * Clang looks in non 'usr' paths based on <sysroot><br></blockquote><div><br></div><div>This is definitely reasonable, it's just that we've not taught it about these *specific* path structures.</div>
<div><br></div><div>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.)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Could/should Clang be doing something like this, or am I misconfigured?<br>
<br>
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).<br>
<br>
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)<br>
<br>
Thanks,<br>
David M<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" class="cremed">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank" class="cremed">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</blockquote></div><br></div>