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
