Can I build termux-x11 using Android Studio on an M1 Mac?

[teddyos]

Hi, I'm new to NDK in Android development, so I have no idea what caused these errors below and how to fix them. Thank you for your help!

[twaik]

Termux:X11 can not be built on Windows or Mac hosts because it uses linux-specific tools during build. It is not going to be fixed, porting these tools and creating reliable reproducible way for building termux-x11 is pretty much complicated and out of scope of this project.

[teddyos]

Thank you for the information! I should have asked this sooner 😂

[Biswa96]

Termux:X11 can not be built on Windows or Mac hosts because it uses linux-specific tools during build.

I have compiled the APK in Windows without any major issue. Two tiny changes are required.

1. Fix the compilation of host program, though it is somewhat a workaround in first place.

--- a/app/src/main/cpp/recipes/xkbcomp.cmake
+++ b/app/src/main/cpp/recipes/xkbcomp.cmake
@@ -4,7 +4,7 @@ file(MAKE_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}/X11")

 add_custom_command(
         OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/ks_tables.h"
-        COMMAND "/usr/bin/gcc" "-o" "${CMAKE_CURRENT_BINARY_DIR}/makekeys" "${CMAKE_CURRENT_SOURCE_DIR}/libx11/src/util/makekeys.c" "&&"
+        COMMAND "gcc" "-o" "${CMAKE_CURRENT_BINARY_DIR}/makekeys" "${CMAKE_CURRENT_SOURCE_DIR}/libx11/src/util/makekeys.c" "&&"
             "${CMAKE_CURRENT_BINARY_DIR}/makekeys" "keysymdef.h" "XF86keysym.h" "Sunkeysym.h" "DECkeysym.h" "HPkeysym.h" ">" "${CMAKE_CURRENT_BINARY_DIR}/ks_tables.h"
         WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}/xorgproto/include/X11"
         COMMENT "Generating source code (ks_tables.h)"

2. For the case-insensitivity file name, the Xlocale.h in libx11 project gets confused with xlocale.h in NDK. Hence, the following workaround.

--- a/include/X11/Xlocale.h
+++ b/include/X11/Xlocale.h
@@ -32,6 +32,9 @@ from The Open Group.
 #include <X11/Xfuncproto.h>
 #include <X11/Xosdefs.h>

+struct __locale_t;
+typedef struct __locale_t* locale_t;
+
 #include <locale.h>

 #endif /* _X11_XLOCALE_H_ */

[twaik]

1. Fix the compilation of host program, though it is somewhat a workaround in first place.

It requires installing gcc and python in windows environment. There are no reliable ways to fetch them automatically with gradle.

[Biswa96]

There are no reliable ways to fetch them automatically with gradle.

Let cmake fetch them - that's what I learn from https://discourse.cmake.org/t/building-compile-time-tools-when-cross-compiling/601/6. Though, it's a bit complicated for such simple task. I presume the process would be easier in macos.

OP probably stuck in the second case about xlocale.h.

[twaik]

I do not think ExternalProject feature can help in this case.

[Biswa96]

It requires installing gcc and python in windows environment. There are no reliable ways to fetch them automatically with gradle.

The clang compiler from NDK can be used to build the makekeys program for host system. I have tested that in Windows. Here is the diff.

--- a/app/src/main/cpp/recipes/xkbcomp.cmake
+++ b/app/src/main/cpp/recipes/xkbcomp.cmake
@@ -4,7 +4,7 @@ file(MAKE_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}/X11")

 add_custom_command(
         OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/ks_tables.h"
-        COMMAND "/usr/bin/gcc" "-o" "${CMAKE_CURRENT_BINARY_DIR}/makekeys" "${CMAKE_CURRENT_SOURCE_DIR}/libx11/src/util/makekeys.c" "&&"
+        COMMAND "${CMAKE_C_COMPILER}" "-o" "${CMAKE_CURRENT_BINARY_DIR}/makekeys" "${CMAKE_CURRENT_SOURCE_DIR}/libx11/src/util/makekeys.c" "&&"
             "${CMAKE_CURRENT_BINARY_DIR}/makekeys" "keysymdef.h" "XF86keysym.h" "Sunkeysym.h" "DECkeysym.h" "HPkeysym.h" ">" "${CMAKE_CURRENT_BINARY_DIR}/ks_tables.h"
         WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}/xorgproto/include/X11"
         COMMENT "Generating source code (ks_tables.h)"

[twaik]

I am not so sure. NDK creates linux executables, not windows. And I do not know why it worked in your case.

[teddyos]

2. For the case-insensitivity file name, the Xlocale.h in libx11 project gets confused with xlocale.h in NDK. Hence, the following workaround.

Thank you for your help, the xlocale.h errors are gone 🙏. But now I am stuck with the gl.h errors. Previously, I replaced all #include <GL/gl.h> with #include <GLES/gl.h>. Not sure if it was the cause.

I think I will use a Linux VM as a last resort.

[twaik]

#include <GL/gl.h> is there on purpose. This file is generated during build.

[Biswa96]

I am not so sure. NDK creates linux executables, not windows. And I do not know why it worked in your case.

I forgot that I am running the gradle script in an environment with mingw-w64 toolchain. So, the NDK clang picks up the system headers and libraries. Hence "There are no reliable ways to fetch them automatically with gradle."

But it is not always correct to assume that NDK will always create ELF binaries. NDK is built with LLVM_DEFAULT_TARGET_TRIPLE option which sets default target to host system. See https://llvm.org/docs/CMake.html. Source at https://android.googlesource.com/toolchain/llvm_android

$ rg LLVM_DEFAULT_TARGET_TRIPLE
configs.py
422:        defines['LLVM_DEFAULT_TARGET_TRIPLE'] = self.llvm_triple

[twaik]

I am pretty much sure NDK does not support building PE executables. Mostly because it is created to build android executables and libraries.