Re: Cross-compilation

[Frederik Seiffert]

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 <address@hidden>:
> 
> 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
>