From: SourceForge.net <no...@so...> - 2008-04-01 22:39:15
|
Bugs item #1931097, was opened at 2008-04-01 10:53 Message generated for change (Comment added) 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: None 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:39 Message: Logged In: YES user_id=1804953 Originator: YES sorry for reopening the bug with a changed subject, instead of opening a new one. as for helping, i'd like to help, but will be busy in the next few months. i hope to help afterwards. what do you think is the best way to migrate? to create a parallel build infrastructure (based on automake), and replace the current one once the new one appears to work? would i need cvs access, or should i send changes by email? ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2008-04-01 22:32 Message: Logged In: YES user_id=5735 Originator: NO bug tracker is for tracking bugs - _one_ issue per tracker item. mailing lists are for general discussions. please use the appropriate venue. that said, our build infrastructure does need upgrading to automake. would you like to work on that? ---------------------------------------------------------------------- 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 |