Re: Cross-compilation

[Ladislav Michl]

Hi Fred,

(hmm, so top posting and lines longer than 80 characters are
fine on GNUstep lists? No offense, just asking.)

On Fri, Jan 10, 2020 at 02:48:16PM +0100, Fred Kiefer wrote:
> 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.

That is, or should be, correct as explained in previous mail. Also note
I'm not setting both „host“ and „target“, but „host“ and „build“.
This is ussual difference between cross and target package.

Also, configure do not need to be pointed to anything, it is not supposed
to work this way and giving it target triplet should make it work.

But neither gnustep-tools nor gnustep-base configure.ac is not written
this way, but various hacks are used instead.

> If you find out more, please report this to the mailing list and document it.

Well, I need to figure out how it is meant to work. Even git history is not
giving any clue.

Thank you,
        ladis

> 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
> >