Android NDK compatibility patch for Debug+Asserts build

[Jeffrey Brusseau]

On Thu, Sep 11, 2014 at 4:44 PM, Jonathan Roelofs <jonathan at codesourcery.com
> wrote:

> +llvm-commits, as it's better to keep this discussion on-list so other
> people can chime in.
>

Oops, I thought I was automatically replying to the list.


>
> On 9/11/14 3:22 PM, Jeffrey Brusseau wrote:
>
>>
>>
>> On Thu, Sep 11, 2014 at 11:22 AM, Jonathan Roelofs <
>> jonathan at codesourcery.com
>> <mailto:jonathan at codesourcery.com>> wrote:
>>
>>     Imagine for a moment using clang on android to cross compile to
>> another
>>     target where, say, fstat64 was supported: that would no longer work
>> with
>>     this patch. Did you run `make check-all` after building with your
>> patch?
>>     This looks to me like it breaks a lot of other targets, and doesn't
>> actually
>>     help you "build clang/llvm on android"....
>>
>> Right I didn't think that actually. I'll see what I can change there.
>>
>>
>>     What build errors were you running into that led you to write this
>> patch?
>>
>>
>> When compiling LTOCodeGenerator.cpp, I got "error: redefinition of
>> 'fstat'"
>> (along with 'lstat' and 'stat') in TargetLibraryInfo.h. I figured out
>> that it's
>> because in android's stat.h they #define stat64, fstat64 and lstat64 to
>> those
>> name. (I'm guessing because they don't want to cover open64 extensions
>> but stay
>> compatible with things looking for them) So because the real fstat etc.
>> are put
>> there as well they show up twice when stat.h is included in
>> LTOCodeGenerator.cpp.
>>
> Ah, now I understand your patch.
>
>>
>> So because of that change I then get "error: 'stat64' is not a member of
>> 'llvm::LibFunc'" (with lstat and fstat respectively) in FunctionAttrs.cpp
>> and
>> TargetLibraryInfo.cpp.
>>
>> My thought was that Android doesn't really support those extensions
>> anyway so
>> yanking them out would be the best course but I forgot about cross
>> compiling to
>> other targets.
>>
>> Maybe if I can tell it to not include stat.h when compiling for android
>> and in
>> it's place build another library to do what LTOCodeGenerator.cpp needs it
>> for?
>>
> 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.
>

In the case of LTOCodeGenerator.cpp, FileSystem.h is where stat.h gets
included, then further down TargetLibraryInfo.h is included.


>> Then
>>
>>
>>     On 9/11/14 9:24 AM, Jeffrey Brusseau wrote:
>>
>>         This is my first patch. I don't expect it's the best way to do
>> things
>>         but this
>>         is at least a start. If you have any suggestions on how to
>> improve it
>>         I'm open
>>         to being ridiculed in all manner of ways.
>>
>>         This patch is to add support for compiling LLVM/Clang for use on
>> Android
>>         using
>>         the NDK toolchain (GCC-4.8). For the most part I compiled this
>> using the
>>         default
>>         configuration:
>>
>>              ../llvm/configure --enable-targets=host
>> --host=arm-linux-androideabi
>>
>>     It's okay to leave off the '--enable-targets=host', and in fact when
>> you run
>>     `make check-all` it will get you better test coverage if you do.  I
>> think
>>     --host should also be autodetected, so you can leave that off too.
>>
>> If I leave off --host will it still use arm-linux-androideabi-gcc to
>> compile
>> everything?
>>
> It will use whatever it discovers CC and CXX happen to be, which I think
> will be that.
>

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.


>>              --prefix=/home/bobajeff/__android-ext
>>
>>         So I wound up compiling the Debug+Asserts build. I will test
>> compiling
>>         Release
>>         (optimized) build if that's requested. I've had experience
>> building a
>>         optimized
>>         build before using Mozilla's Fastcomp fork but that needed a
>> different
>>         set of
>>         patches.
>>
>>     Should be as easy as `make ENABLE_OPTIMIZED=1`, and it's definitely a
>> good
>>     thing to check along with `make ENABLE_OPTIMIZED=1 check-all` (which
>> runs
>>     the Release+Asserts tests).
>>
>>
>> Alright, I'll try that with the next build.
>>
>>
>>
>>     Cheers,
>>
>>     Jon
>>
>>
>>
>>
>>         _________________________________________________
>>         llvm-commits mailing list
>>         llvm-commits at cs.uiuc.edu <mailto:llvm-commits at cs.uiuc.edu>
>>         http://lists.cs.uiuc.edu/__mailman/listinfo/llvm-commits
>>         <http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits>
>>
>>
>>     --
>>     Jon Roelofs
>>     jonathan at codesourcery.com <mailto:jonathan at codesourcery.com>
>>     CodeSourcery / Mentor Embedded
>>
>>
>>
> --
> Jon Roelofs
> jonathan at codesourcery.com
> CodeSourcery / Mentor Embedded
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140912/c4a2a3d4/attachment.html>