Re: Cross-compilation

[Fred Kiefer]

First off, I tried to run GNUstep cross compilation ages ago and never 
succeeded and I didn’t hear that things improved in between. But for your 
specific problem it looks like you set „target“ when building make and later 
when building base you set both „host“ and „target“. And what is more 
important, you did not point make to the correct gcc to use for cross 
compilation. As the warning suggest your need to set 
"CC=arm-v7a-linux-gnueabi-gcc“. Even with that and a few more things correctly 
setup I failed and if I remember correctly this was due to the fact that we 
have some helper tools that needs to be compiled for the build system. Of 
course all the auto configure stuff also fails as it is not able to detect the 
correct settings for the target system.
If you find out more, please report this to the mailing list and document it.

Fred

> Am 10.01.2020 um 13:00 schrieb Ladislav Michl <address@hidden>:
> 
> 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
>