Even with --target=i586-mingw32 it stops at exactly the same point.
While building gnustep-objc-1.6.0 works perfectly with:
So I suspect it is something in configure. The config.log reports:
configure:16547: result: none
configure:16572: error: Incomplete support for ffi functionality.
Even installing ffcall within the GNUstep directory layout ends with
same story. So something is wrong somewhere... but I can't figure out
what. Pointers where to look, even the obvious, because I am surely
And completely agree with the proposed changes of the variables and the
use of host=
Thanks (again) ;),
Nicola Pero wrote:
To bring everything in line with the standard GNU/autoconf
terminology, we probably need to rename a lot of variables inside
gnustep-make, and then rename all options. :-(
So, to explain, the right thing to do would be:
core/make/configure --build=xxx host=yyy target=zzz
'xxx' is only used while building gnustep-make, and it would then be
thrown away. Currently, it is in fact thrown away. :-)
This sounds reasonable.
'yyy' is the machine that gnustep-make will run on. This would be
stored in 'GNUSTEP_BUILD' runtime/shell/makefile variables; because
when gnustep-make is used to compile, it would be the 'build' machine
on which the compilation is running. Currently this is instead
stored in the 'GNUSTEP_HOST' variables, which is confusing. :-(
Couldn't agree more
'zzz' is the machine that executables created by gnustep-make will
run on. This would be stored in 'GNUSTEP_HOST'
runtime/shell/makefile variables; because when gnustep-make is used
to compile, it would be the 'host' machine on which the compiled
programs will be running. Currently this is instead stored in the
'GNUSTEP_TARGET' variables, which is confusing. :-/
And then, it would become natural to use 'host=xxx' everywhere, in
configure and make arguments, to turn on cross-compilation when using
gnustep-make as a compilation tool. This is exactly what the
GNU/autoconf standard interpretation requires. :-)
Yippie, this sounds logical to me!
To keep things backwards compatible, we could try to detect 'make
target=xxx', print a warning, and execute it as if 'make host=xxx'
had been specified; the same for './configure --target=xxx' which
would temporarily emit a warning and be converted into './configure
Also, we could set GNUSTEP_TARGET_xxx and other variables to be the
same as GNUSTEP_HOST_xxx so that old GNUmakefiles will keep working.
Comments welcome ;-)
Discuss-gnustep mailing list