<div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote">On Thu, Sep 11, 2014 at 4:44 PM, Jonathan Roelofs <span dir="ltr"><<a href="mailto:jonathan@codesourcery.com" target="_blank">jonathan@codesourcery.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">+llvm-commits, as it's better to keep this discussion on-list so other people can chime in.<span class=""><br></span></blockquote><div> </div><div>Oops, I thought I was automatically replying to the list. <br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
<br>
<br>
On 9/11/14 3:22 PM, Jeffrey Brusseau wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
<br>
<br>
On Thu, Sep 11, 2014 at 11:22 AM, Jonathan Roelofs <<a href="mailto:jonathan@codesourcery.com" target="_blank">jonathan@codesourcery.com</a><br></span><span class="">
<mailto:<a href="mailto:jonathan@codesourcery.com" target="_blank">jonathan@codesourcery.<u></u>com</a>>> wrote:<br>
<br>
    Imagine for a moment using clang on android to cross compile to another<br>
    target where, say, fstat64 was supported: that would no longer work with<br>
    this patch. Did you run `make check-all` after building with your patch?<br>
    This looks to me like it breaks a lot of other targets, and doesn't actually<br>
    help you "build clang/llvm on android"....<br>
<br>
Right I didn't think that actually. I'll see what I can change there.<br>
<br>
<br>
    What build errors were you running into that led you to write this patch?<br>
<br>
<br>
When compiling LTOCodeGenerator.cpp, I got "error: redefinition of 'fstat'"<br>
(along with 'lstat' and 'stat') in TargetLibraryInfo.h. I figured out that it's<br>
because in android's stat.h they #define stat64, fstat64 and lstat64 to those<br>
name. (I'm guessing because they don't want to cover open64 extensions but stay<br>
compatible with things looking for them) So because the real fstat etc. are put<br>
there as well they show up twice when stat.h is included in LTOCodeGenerator.cpp.<br>
</span></blockquote>
Ah, now I understand your patch.<span class=""><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
So because of that change I then get "error: 'stat64' is not a member of<br>
'llvm::LibFunc'" (with lstat and fstat respectively) in FunctionAttrs.cpp and<br>
TargetLibraryInfo.cpp.<br>
<br>
My thought was that Android doesn't really support those extensions anyway so<br>
yanking them out would be the best course but I forgot about cross compiling to<br>
other targets.<br>
<br>
Maybe if I can tell it to not include stat.h when compiling for android and in<br>
it's place build another library to do what LTOCodeGenerator.cpp needs it for?<br>
</blockquote></span>
What does the chain of includes look like where both TargetLibraryInfo.h and stat.h get included? It might be possible to move the stat.h include out of the header that it is in and into the corresponding cpp file. I suppose it depends on what declarations the include is being used for.<span class=""><br></span></blockquote><div> </div><div>In the case of LTOCodeGenerator.cpp, FileSystem.h is where stat.h gets included, then further down TargetLibraryInfo.h is included.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Then<br>
<br>
<br>
    On 9/11/14 9:24 AM, Jeffrey Brusseau wrote:<br>
<br>
        This is my first patch. I don't expect it's the best way to do things<br>
        but this<br>
        is at least a start. If you have any suggestions on how to improve it<br>
        I'm open<br>
        to being ridiculed in all manner of ways.<br>
<br>
        This patch is to add support for compiling LLVM/Clang for use on Android<br>
        using<br>
        the NDK toolchain (GCC-4.8). For the most part I compiled this using the<br>
        default<br>
        configuration:<br>
<br>
             ../llvm/configure --enable-targets=host --host=arm-linux-androideabi<br>
<br>
    It's okay to leave off the '--enable-targets=host', and in fact when you run<br>
    `make check-all` it will get you better test coverage if you do.  I think<br>
    --host should also be autodetected, so you can leave that off too.<br>
<br>
If I leave off --host will it still use arm-linux-androideabi-gcc to compile<br>
everything?<br>
</blockquote></span>
It will use whatever it discovers CC and CXX happen to be, which I think will be that. <br></blockquote><div> </div><div>I'll try that at first with a quick make -n to make sure. I suppose I can just manually set CC and CXX if that doesn't work.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
             --prefix=/home/bobajeff/__<u></u>android-ext<span class=""><br>
<br>
        So I wound up compiling the Debug+Asserts build. I will test compiling<br>
        Release<br>
        (optimized) build if that's requested. I've had experience building a<br>
        optimized<br>
        build before using Mozilla's Fastcomp fork but that needed a different<br>
        set of<br>
        patches.<br>
<br>
    Should be as easy as `make ENABLE_OPTIMIZED=1`, and it's definitely a good<br>
    thing to check along with `make ENABLE_OPTIMIZED=1 check-all` (which runs<br>
    the Release+Asserts tests).<br>
<br>
<br>
Alright, I'll try that with the next build.<br>
<br>
<br>
<br>
    Cheers,<br>
<br>
    Jon<br>
<br>
<br>
<br>
<br></span>
        ______________________________<u></u>___________________<br>
        llvm-commits mailing list<br>
        <a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a> <mailto:<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.<u></u>edu</a>><br>
        <a href="http://lists.cs.uiuc.edu/__mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/__<u></u>mailman/listinfo/llvm-commits</a><span class=""><br>
        <<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvm-commits</a>><br>
<br>
<br>
    --<br>
    Jon Roelofs<br></span>
    <a href="mailto:jonathan@codesourcery.com" target="_blank">jonathan@codesourcery.com</a> <mailto:<a href="mailto:jonathan@codesourcery.com" target="_blank">jonathan@codesourcery.<u></u>com</a>><br>
    CodeSourcery / Mentor Embedded<br>
<br>
<br>
</blockquote><div class=""><div class="h5">
<br>
-- <br>
Jon Roelofs<br>
<a href="mailto:jonathan@codesourcery.com" target="_blank">jonathan@codesourcery.com</a><br>
CodeSourcery / Mentor Embedded<br>
</div></div></blockquote></div><br></div></div></div>