[ clisp-Bugs-1931097 ] cross-compile does not work

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Bugs item #1931097, was opened at 2008-04-01 10:53
Message generated for change (Settings changed) made by vvv2
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1931097&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: build problems
Status: Open
Resolution: Fixed
>Priority: 2
Private: No
Submitted By: Vladimir Volovich (vvv2)
Assigned to: Sam Steingold (sds)
Summary: cross-compile does not work

Initial Comment:
i configured clisp on linux using --host=i586-mingw32msvc
and make fails with

echo '#include "config.h"' > tmp.c
cat '/home/vvv/src/clisp/clisp-cvs/src/intparam.c' >> tmp.c
i586-mingw32msvc-gcc tmp.c -o intparam
./intparam > intparam.h
/bin/sh: ./intparam: cannot execute binary file
make: *** [intparam.h] Error 126

because it tries to run the woe32 executable:

$ file intparam
intparam: MS-DOS executable PE  for MS Windows (console) Intel 80386 32-bit

----------------------------------------------------------------------

Comment By: Vladimir Volovich (vvv2)
Date: 2008-04-01 22:18

Message:
Logged In: YES 
user_id=1804953
Originator: YES

hm - i saw your note in the NEWS file that "Cross-compilation process has
been restored to its former glory",
but it seems to be far from that yet (assuming cross-compilation formerly
worked, which i don't know ;)).

i looked at clisp/configure, clisp/src/configure and
clisp/src/makemake.in

first i noticed that clisp/src/configure determines whether there's a
cross-compilation taking place, but makemake.in checks if it's the case by
looking if the "cross" was passed in command line to it (line 573), but it
seems nowhere to be passed by the configure, so makemake unconditionally
thinks that there's no cross-compilation.

therefore, your fix which put the differing behavior under if [ $CROSS =
true ] will not be triggered (because CROSS will never be set to true in
makemake.in).

also, why is there srcdir='../src' on line 576 of makemake.in? if i build
outside of the source tree, it may not be the case, and it seems strange
that srcdir needs to be set here.

also, the case branch *) at makemake.in:573 contains some hardwired
limitations on compiler names and supported systems. this branch is used
not only for cross-compilation though, but there's no cross
compilation-related settings in 0 | 1) branch at makemake.in:500.

why is not cross-compilation passed by configure into makemake.in as one
of @variables@?

makemake.in:651 assumes special name for cross-compiler, which is
completely different from what is used by src/configure:1469
(i.e. src/configure uses host_alias as a prefix to compiler name and its
tools, but makemake.in use gcc- as a prefix and host as suffix).
why makemake.in is not using whatever configure has determined, but tries
to reset to some hardwired settings?

also top-level configure has --build option which clashes with the usual
cross-compilation-related --build option used in src/configure
(i.e. --build means completely different thing for top-level configure,
and there's no way to pass it to src/configure).

in other words, cross-compilation does not work in current sources.

i'm using debian distribution, and installed its standard packages for
cross-compiling: mingw32, mingw32-binutils, mingw32-runtime.
if you want to fix cross-compilation, if you have a debian system, or
another linux distribution which has mingw32 cross-compiler, could you try
to compile clisp with it?
otherwise reporting bugs one by one will take years. :)

i don't consider this high-priority, because it seems that it's not easy
to fix current sources to support cross-compilation,
and i can use "normal" build. but please at least change the NEWS file to
not say that cross-compilation works.

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2008-04-01 19:18

Message:
Logged In: YES 
user_id=5735
Originator: NO

(PARAMS) [CROSS]: use touch, not executables, for
intparam and floatparam because the constants are defined in config.h
(UTILCC) [CROSS]: define to cc instead of $(CC) because the
utilities (gctrigger et al) must run locally

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2008-04-01 19:18

Message:
Logged In: YES 
user_id=5735
Originator: NO

thank you for your bug report.
the bug has been fixed in the CVS tree.
you can either wait for the next release (recommended)
or check out the current CVS tree (see http://clisp.cons.org)
and build CLISP from the sources (be advised that between
releases the CVS tree is very unstable and may not even build
on your platform).

----------------------------------------------------------------------

Comment By: Vladimir Volovich (vvv2)
Date: 2008-04-01 12:01

Message:
Logged In: YES 
user_id=1804953
Originator: YES

additional note:
intparam.h (and floatparam.h) are generated by configure, but Makefile
contains rules to build them the same way as for "native" builds.

if i remove the rules to build intparam.h and floatparam.h, i proceed
further, until
comment5, gctrigger, varbrace are built by a cross-compiler but attempted
to be run in Makefile:

./comment5 /home/vvv/src/clisp/clisp-cvs/src/spvw.d | ./gctrigger |
./varbrace > spvw.c
/bin/sh: ./gctrigger: cannot execute binary file
/bin/sh: ./comment5: cannot execute binary file
/bin/sh: ./varbrace: cannot execute binary file
make: *** [spvw.c] Error 126

could/should they be built native CC?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1931097&group_id=1355