gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cross-compilation


From: Ladislav Michl
Subject: Re: Cross-compilation
Date: Fri, 10 Jan 2020 15:46:47 +0100

Hi Frederik,

On Fri, Jan 10, 2020 at 02:59:03PM +0100, Frederik Seiffert wrote:
> 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

This one I already evaluated, it sets --host even on gnustep-make
package, but this package is not target, but cross one.

> Hope that helps, and let me know if you have any questions.

Yes, those I already asked :) In case even gnustep-make is target package,
I can live with that, but then I need to hack my cross build enviroment
to accept this exception, just because it is ... exception. I'm not aware
any other package being setup this way.

Thank you,
        ladis

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]