Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Trouble building arm64-v8a android  (Read 3648 times)

0 Members and 1 Guest are viewing this topic.

jheinz

  • Newbie
  • *
  • Posts: 2
    • View Profile
    • Email
Trouble building arm64-v8a android
« on: April 14, 2016, 10:57:32 pm »
Hey everybody,

I've been using SFML for awhile, and recently I've been looking into creating android apps. Since I'm familiar with SFML, I thought I'd try out the experimental android port. I've managed to compile armeabi and armeabi-v7a targets, but I'm currently trying to figure out how to get arm64-v8a to compile. This is the output of make:
Code: [Select]

Scanning dependencies of target sfml-system
[  1%] Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/Clock.cpp.o
[  2%] Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/Err.cpp.o
In file included from (NDK)/platforms/android-21/arch-arm64/usr/include/signal.h:37:0,
                 from (NDK)/platforms/android-21/arch-arm64/usr/include/pthread.h:33,
                 from (NDK)/sources/cxx-stl/llvm-libc++/libcxx/include/__mutex_base:17,
                 from (NDK)/sources/cxx-stl/llvm-libc++/libcxx/include/mutex:176,
                 from (NDK)/sources/cxx-stl/llvm-libc++/libcxx/include/__locale:18,
                 from (NDK)/sources/cxx-stl/llvm-libc++/libcxx/include/ios:216,
                 from (NDK)/sources/cxx-stl/llvm-libc++/libcxx/include/ostream:131,
                 from SFML-2.3.2/include/SFML/System/Err.hpp:32,
                 from SFML-2.3.2/src/SFML/System/Err.cpp:28:
(NDK)/platforms/android-21/arch-arm64/usr/include/asm/sigcontext.h:45:2: error: '__uint128_t' does not name a type
  __uint128_t vregs[32];
  ^
make[2]: *** [src/SFML/System/CMakeFiles/sfml-system.dir/Err.cpp.o] Error 1
make[1]: *** [src/SFML/System/CMakeFiles/sfml-system.dir/all] Error 2
make: *** [all] Error 2


This is the file that generates the error, it appears that even editing it will not do anything (although I may be wrong):

Code: [Select]

/****************************************************************************
 ****************************************************************************
 ***
 ***   This header was automatically generated from a Linux kernel header
 ***   of the same name, to make information necessary for userspace to
 ***   call into the kernel available to libc.  It contains only constants,
 ***   structures, and macros generated from the original header, and thus,
 ***   contains no copyrightable information.
 ***
 ***   To edit the content of this header, modify the corresponding
 ***   source file (e.g. under external/kernel-headers/original/) then
 ***   run bionic/libc/kernel/tools/update_all.py
 ***
 ***   Any manual change here will be lost the next time this script will
 ***   be run. You've been warned!
 ***
 ****************************************************************************
 ****************************************************************************/
#ifndef _UAPI__ASM_SIGCONTEXT_H
#define _UAPI__ASM_SIGCONTEXT_H
#include <linux/types.h>
struct sigcontext {
/* WARNING: DO NOT EDIT, AUTO-GENERATED CODE - SEE TOP FOR INSTRUCTIONS */
 __u64 fault_address;
 __u64 regs[31];
 __u64 sp;
 __u64 pc;
/* WARNING: DO NOT EDIT, AUTO-GENERATED CODE - SEE TOP FOR INSTRUCTIONS */
 __u64 pstate;
 __u8 __reserved[4096] __attribute__((__aligned__(16)));
};
struct _aarch64_ctx {
/* WARNING: DO NOT EDIT, AUTO-GENERATED CODE - SEE TOP FOR INSTRUCTIONS */
 __u32 magic;
 __u32 size;
};
#define FPSIMD_MAGIC 0x46508001
/* WARNING: DO NOT EDIT, AUTO-GENERATED CODE - SEE TOP FOR INSTRUCTIONS */
struct fpsimd_context {
 struct _aarch64_ctx head;
 __u32 fpsr;
 __u32 fpcr;
/* WARNING: DO NOT EDIT, AUTO-GENERATED CODE - SEE TOP FOR INSTRUCTIONS */
 __uint128_t vregs[32];
};
#endif


If anyone has a clue how to get around this, that'd be awesome. Thanks!

chrisvarns

  • Newbie
  • *
  • Posts: 1
    • View Profile
Re: Trouble building arm64-v8a android
« Reply #1 on: July 10, 2017, 05:24:49 pm »
Very late reply I know. I think the issue is that it is compiling with the 32 bit toolchain from the NDK, which does not define that type. I am having that exact problem right now building the dependencies (openal-soft). It is misleading as it is including the 64 bit headers.

I managed to get past this by downgrading my NDK to r10e, as it "just works" with that.