When trying to compile a simple test file with Blackhole under Mingw/MSys I get
~ $ bh compile foo.scm
gcc: error: foo-rt.c: No such file or directory gcc: fatal error: no input files compilation terminated. gcc: error: foo-ct.c: No such file or directory gcc: fatal error: no input files compilation terminated. gcc: error: foo-vt.c: No such file or directory gcc: fatal error: no input files compilation terminated. gcc: error: foo-mi.c: No such file or directory gcc: fatal error: no input files compilation terminated. gcc: error: foo.o1.c: No such file or directory gcc: fatal error: no input files compilation terminated.
Any clues?
Also when trying to compile the BH with --enable-single-host'ed Gambit I ran out of memory, is that to be expected? ISTR it has worked in the past... Without --enable-single-host it compiles just fine though.
Afficher les réponses par date
2012/10/4 Tomi Neste tomi.neste@gmail.com
When trying to compile a simple test file with Blackhole under Mingw/MSys I get
~ $ bh compile foo.scm
gcc: error: foo-rt.c: No such file or directory gcc: fatal error: no input files compilation terminated. gcc: error: foo-ct.c: No such file or directory gcc: fatal error: no input files compilation terminated. gcc: error: foo-vt.c: No such file or directory gcc: fatal error: no input files compilation terminated. gcc: error: foo-mi.c: No such file or directory gcc: fatal error: no input files compilation terminated. gcc: error: foo.o1.c: No such file or directory gcc: fatal error: no input files compilation terminated.
Any clues?
Turn on the GSC_CC_VERBOSE or sth like this environment variable, so that the gsc_cc.bat file will print out the full path it executes (check that script, it's in Gambit's bin directory), i.e.
cmd set GS_CC_VERBOSE=TRUE gsc [module-compile! etc .]
Also when trying to compile the BH with --enable-single-host'ed Gambit I ran out of memory, is that to be expected?
How much memory are we speaking about?
As posted on this ML some months ago (by Alex?), excessive RAM use was reported as a bug to the gcc time and they did something about it, so getting a very new gcc version could solve it. (The Gambit-generated code is *full* of goto:s and there's some optimization per goto that cost lots of RAM, in newer GCC versions it shuts off that optimization above a certain number of goto:s, as for the RAM use not to become excessive like 75GB etc.)
ISTR it has worked in the past... Without --enable-single-host it compiles just fine though.
Mm, without it the C code is less complex
You should clearly get it going. Please tell about your next outcomes with this.
--
tomppa _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
I think I got it working now. Apparently the actual problem was the redirection to /dev/null in compile-sexp-to-c at compile-load.scm. Changing that to something else fixed it. There is also another /dev/null redirection in the lib.scm which might too cause problems.
Also when trying to compile the BH with --enable-single-host'ed Gambit I ran out of memory, is that to be expected?
How much memory are we speaking about?
It's 2 gt Windows 7/32 netbook with GCC 4.7.0.
Hi, aha cool. Can you paste a patch here with what you did?
Or even better, make a universal patch that solves this in such a way that functionality is maintained (more than now) on all platforms and commit it on Github?
2012/10/5 Tomi Neste tomi.neste@gmail.com
I think I got it working now. Apparently the actual problem was the redirection to /dev/null in compile-sexp-to-c at compile-load.scm. Changing that to something else fixed it. There is also another /dev/null redirection in the lib.scm which might too cause problems.
Also when trying to compile the BH with --enable-single-host'ed Gambit I ran out of memory, is that to be expected?
How much memory are we speaking about?
It's 2 gt Windows 7/32 netbook with GCC 4.7.0.
-- tomppa
On Oct 5, 2012 7:36 PM, "Mikael" mikael.rcv@gmail.com wrote:
Hi, aha cool. Can you paste a patch here with what you did?
Or even better, make a universal patch that solves this in such a way
that functionality is maintained (more than now) on all platforms and commit it on Github?
I just replaced the /dev/null with a temp file. I'll have to check if something more refined is needed as I haven't had much time to test it all yet.
-- tomppa