discuss-gnustep
[Top][All Lists]
Advanced

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

Re: gnustep-base: cross compiler help


From: Dennis Leeuw
Subject: Re: gnustep-base: cross compiler help
Date: Thu, 10 Jan 2008 19:15:28 +0100
User-agent: Icedove 1.5.0.14pre (X11/20071018)

Solved it! Apparently for ffcall ranlib was not run over the installed .a's doing it manually solved the issue...

Dennis

Dennis Leeuw wrote:
Even with --target=i586-mingw32 it stops at exactly the same point.
While building gnustep-objc-1.6.0 works perfectly with:
make target=i586-mingw32

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 overlooking something?

And completely agree with the proposed changes of the variables and the use of host=

Thanks (again) ;),

Dennis

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. :-/

Yep!


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
--host=xxx'. :-)

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

Thanks





_______________________________________________
Discuss-gnustep mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/discuss-gnustep







reply via email to

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