Hi Ladislav, You might want to have a look at the scripts of the GNUstep Android toolchain project, which cross-compiles GNUstep for Android: http://github.com/gnustep/tools-android
Hope that helps, and let me know if you have any questions. Frederik > Am 10.01.2020 um 13:00 schrieb Ladislav Michl <la...@linux-mips.org>: > > Hi there, > > I'm considering gnustep-make to be a (cross)tool, similar binutils is, which > seems to match chapter '1.2.5 Configuring for a cross-compile target' of the > INSTALL file: > https://github.com/gnustep/tools-make/blob/master/INSTALL#L154 > > However running > ./configure --target=arm-v7a-linux-gnueabi > gives: > checking build system type... x86_64-pc-linux-gnu > checking host system type... x86_64-pc-linux-gnu > checking target system type... arm-v7a-linux-gnueabi > checking for pkgconfig... yes > checking for library combo... gnu-gnu-gnu > checking for gcc... gcc > checking whether the C compiler works... yes > checking for C compiler default output file name... a.out > checking for suffix of executables... > checking whether we are cross compiling... no > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ISO C89... none needed > checking how to run the C preprocessor... gcc -E > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking for grep that handles long lines and -e... /usr/bin/grep > checking for egrep... /usr/bin/grep -E > checking for apple compiler flags... yes > cross compiling from x86_64-pc-linux-gnu to arm-v7a-linux-gnueabi .. > checking for arm-v7a-linux-gnueabi-gcc... gcc > checking for arm-v7a-linux-gnueabi-ranlib... arm-v7a-linux-gnueabi-ranlib > checking for arm-v7a-linux-gnueabi-ar... arm-v7a-linux-gnueabi-ar > checking for arm-v7a-linux-gnueabi-dlltool... dlltool > > As you can see ggc is still host gcc which later gives for gnustep-base > (that is a target package): > ./configure --build=x86_64-host-linux-gnu --host=arm-v7a-linux-gnueabi > checking build system type... x86_64-host-linux-gnu > checking host system type... arm-v7a-linux-gnueabi > checking target system type... arm-v7a-linux-gnueabi > ... > configure: WARNING: You are running configure with the compiler > (arm-v7a-linux-gnueabi-gcc) set to a different value from that used by > gnustep-make (gcc). To avoid conflicts/problems, reconfigure/reinstall > gnustep-make to use CC=arm-v7a-linux-gnueabi-gcc or run the gnustep-base > configure again with your CC environment variable set to gcc > configure: WARNING: You are running configure with the preprocessor > (arm-v7a-linux-gnueabi-gcc -E) set to a different value from that used by > gnustep-make (gcc -E). To avoid conflicts/problems, reconfigure/reinstall > gnustep-make to use CPP=arm-v7a-linux-gnueabi-gcc -E or run the gnustep-base > configure again with your CPP environment variable set to gcc -E > configure: WARNING: You are running configure with the compiler > (arm-v7a-linux-gnueabi-g++) set to a different value from that used by > gnustep-make (g++). To avoid conflicts/problems, reconfigure/reinstall > gnustep-make to use CXX=arm-v7a-linux-gnueabi-g++ or run the gnustep-base > configure again with your CXX environment variable set to g++ > checking for arm-v7a-linux-gnueabi-gcc... arm-v7a-linux-gnueabi-gcc > checking whether the C compiler works... yes > checking for C compiler default output file name... a.out > checking for suffix of executables... > checking whether we are cross compiling... yes > > Later compilation fails, which is somewhat expected. > > Looking at gnustep-tools' configure.ac native compiler is set first > (see also above that line): > https://github.com/gnustep/tools-make/blob/master/configure.ac#L119 > here setting CC basically prevents later checks from doing its job: > https://github.com/gnustep/tools-make/blob/master/configure.ac#L236 > Also configure.ac contains a lot of ancient stuff for apple, cygwin > and mingw, which seems quite fragile to touch, so minimal fix could > look like (same for DLLTOOL eventually): > > diff --git a/configure.ac b/configure.ac > index 773bf313..ec45aec4 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -236,6 +236,7 @@ fi > if test "x$target" != "x$host"; then > echo "cross compiling from $host to $target .." > cross_compiling="yes" > + export CC= > if test "$OBJC_RUNTIME_LIB" = ng; then > AC_CHECK_PROG(CC, "${targetArgument}-clang", dnl > "${targetArgument}-clang", clang) > > Also gnustep-base configure.ac contains a call to GNUstep.sh: > https://github.com/gnustep/libs-base/blob/master/configure.ac#L1018 > which alters PATH via GNUstep.sh: > https://github.com/gnustep/tools-make/blob/master/GNUstep.sh.in#L298 > > So even if gnustep base is invoked with correct PATH, after call > to GNUstep.sh this path is "fixed" and system-wide gnustep-config > is used instead of local one, which of course breaks setup. > > Questions are: > - How is GNUstep supposed to be crosscompiled? > - Is there a list of tested targets? > > Thank you, > ladis >
