Hi. Yhc doesn't like being built twice: $ scons configure && scons build # scons install $ scons clean $ scons build ... Checking whether byte ordering is bigendian... (cached) no Checking size of char... (cached) no Checking size of short... (cached) no Checking size of int... (cached) no Checking size of long... (cached) no Checking size of long long... (cached) no Checking size of float... (cached) no Checking size of double... (cached) no Checking size of void*... (cached) no Failed to check types sizes/endianness. You do have a working C compiler don't you? If so then please contact the Yhc developers for help. I had a C compiler a second ago. It seems the scons caching has gone awry: $ rm .sconsign.dblite $ scons build ... builds as usual. Charles.
What good does scons do us? It has given me much grief. Surely cabal can build yhc proper. As for the interpreter: stefan@stefans:/usr/local/src/yhc$ time sh build.yhi.log In file included from src/runtime/BCKernel/mutator.c:108: src/runtime/BCKernel/mutins.h: In function 'run': src/runtime/BCKernel/mutins.h:662: warning: assignment from incompatible pointer type src/runtime/BCKernel/builtin/IORef.c:36:2: warning: no newline at end of file depends/ctypes/libffi/src/x86/ffi.c: In function 'ffi_prep_args': depends/ctypes/libffi/src/x86/ffi.c:108: warning: incompatible implicit declaration of built-in function 'bcopy' depends/ctypes/libffi/src/x86/ffi.c: In function 'ffi_prep_args_raw': depends/ctypes/libffi/src/x86/ffi.c:395: warning: incompatible implicit declaration of built-in function 'bcopy' real 0m10.481s user 0m9.505s sys 0m0.976s stefan@stefans:/usr/local/src/yhc$ cat build.yhi.log #! /bin/sh exec gcc -o yhi -O2 -funit-at-a-time src/runtime/BCKernel/sanity.c src/runtime/BCKernel/basepath.c src/runtime/BCKernel/jonkers.c src/runtime/BCKernel/module.c src/runtime/BCKernel/stopcopy.c src/runtime/BCKernel/mutator.c src/runtime/BCKernel/primitive.c src/runtime/BCKernel/foreign.c src/runtime/BCKernel/hashtable.c src/runtime/BCKernel/heap.c src/runtime/BCKernel/info.c src/runtime/BCKernel/main.c src/runtime/BCKernel/make.c src/runtime/BCKernel/mark.c src/runtime/BCKernel/iofuncs.c src/runtime/BCKernel/pretty.c src/runtime/BCKernel/stable.c src/runtime/BCKernel/process.c src/runtime/BCKernel/profile.c src/runtime/BCKernel/thread.c src/runtime/BCKernel/external.c src/runtime/BCKernel/hsffi.c src/runtime/BCKernel/integer.c src/runtime/BCKernel/builtin/Prelude.c src/runtime/BCKernel/builtin/IO.c src/runtime/BCKernel/builtin/FFI.c src/runtime/BCKernel/builtin/Array.c src/runtime/BCKernel/builtin/System.c src/runtime/BCKernel/builtin/PackedString.c src/runtime/BCKernel/builtin/IORef.c src/runtime/BCKernel/builtin/RuntimeAPI.c src/runtime/BCKernel/builtin/Concurrent.c depends/ctypes/libffi/src/prep_cif.c depends/ctypes/libffi/src/cfield.c depends/ctypes/libffi/src/x86/ffi.c depends/ctypes/libffi/src/x86/sysv.S -lm -lpthread -ldl -lgmp -I. -Idepends/ctypes/libffi/include -Idepends/ctypes/libffi/src/x86 -Idepends/ctypes/libffi -DVERSION=\"0.7.0-20070224144350-custom\" -DX86 stefan@stefans:/usr/local/src/yhc$ IE, less than 6x the time needed to compile a Haskell "hello world" with comparable optimization settings. (For those less familiar with ghc options, -funit-at-a-time means whole program optimization in this context.) We probably don't need separate compilation, let alone dependency generation.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stefan O'Rear wrote: > exec gcc -o yhi -O2 -funit-at-a-time src/runtime/BCKernel/sanity.c src/runtime/BCKernel/basepath.c [...] depends/ctypes/libffi/src/x86/ffi.c depends/ctypes/libffi/src/x86/sysv.S - -lm -lpthread -ldl -lgmp -I. -Idepends/ctypes/libffi/include - -Idepends/ctypes/libffi/src/x86 -Idepends/ctypes/libffi - -DVERSION=\"0.7.0-20070224144350-custom\" -DX86 A few of those paths passed to the compiler include "x86" (also, -DX86). Maybe the choice of files (and other compiler flags), in order to support the FFI on multiple architectures, isn't completely trivial? > IE, less than 6x the time needed to compile a Haskell "hello world" > with comparable optimization settings. (For those less familiar with > ghc options, -funit-at-a-time means whole program optimization in this > context.) We probably don't need separate compilation, let alone > dependency generation. (ghc->gcc) yes http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Optimize-Options.html "Compiling multiple files at once to a single output file (and using - -funit-at-a-time) will allow the compiler to use information gained from all of the files when compiling each of them." It seems, looking at different versions' manuals, gcc 4.1 automatically enables -funit-at-a-time with -O or greater gcc 4.0 automatically enables -funit-at-a-time with -O2 or greater gcc 3.4 (when the flag was introduced) never automatically enables it. So the effect of putting the flag there seems to be better optimization for gcc 3.4 and error for gcc 3.3 and below. Is it worth mentioning the flag? (Also, is yhi supposed to support C compilers other than "gcc", which, among other things, probably don't have that flag?) In any case, you are probably right about that optimization effect when compiling together multiple files at the same time, that it is a good effect, assuming it makes the build process less complicated or at least not more so! Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF4Ka7HgcxvIWYTTURAnuDAJ0WFCz4S3hbNRSihO/zj3/aZMocVwCfSblM RLklk5YRdNeDC6nLlivM+dU= =LNM/ -----END PGP SIGNATURE-----
On Sat, Feb 24, 2007 at 03:57:31PM -0500, Isaac Dupree wrote: > Stefan O'Rear wrote: > > exec gcc -o yhi -O2 -funit-at-a-time src/runtime/BCKernel/sanity.c > src/runtime/BCKernel/basepath.c [...] depends/ctypes/libffi/src/x86/ffi.c > depends/ctypes/libffi/src/x86/sysv.S > - -lm -lpthread -ldl -lgmp -I. -Idepends/ctypes/libffi/include > - -Idepends/ctypes/libffi/src/x86 -Idepends/ctypes/libffi > - -DVERSION=\"0.7.0-20070224144350-custom\" -DX86 > > A few of those paths passed to the compiler include "x86" (also, -DX86). > Maybe the choice of files (and other compiler flags), in order to > support the FFI on multiple architectures, isn't completely trivial? D'oh. Very good point :) > > IE, less than 6x the time needed to compile a Haskell "hello world" > > with comparable optimization settings. (For those less familiar with > > ghc options, -funit-at-a-time means whole program optimization in this > > context.) We probably don't need separate compilation, let alone > > dependency generation. > > (ghc->gcc) yes :) > yes > http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Optimize-Options.html > "Compiling multiple files at once to a single output file (and using > - -funit-at-a-time) will allow the compiler to use information gained from > all of the files when compiling each of them." > It seems, looking at different versions' manuals, > gcc 4.1 automatically enables -funit-at-a-time with -O or greater > gcc 4.0 automatically enables -funit-at-a-time with -O2 or greater > gcc 3.4 (when the flag was introduced) never automatically enables it. > So the effect of putting the flag there seems to be better optimization > for gcc 3.4 and error for gcc 3.3 and below. Is it worth mentioning the > flag? (Also, is yhi supposed to support C compilers other than "gcc", > which, among other things, probably don't have that flag?) Well, when I last used gcc 3.4 WAS the latest version :) (It is amazing how much I do with haskell now.) Anyway, I was going for "highest set of optimization flags I could remember", ie "slowest C compiler I have". So the fact that it is a gcc-specific option is (hopefully!) irrelevant here. > In any case, you are probably right about that optimization effect when > compiling together multiple files at the same time, that it is a good > effect, assuming it makes the build process less complicated or at least > not more so! Stefab
participants (3)
-
charles blundell -
Isaac Dupree -
Stefan O'Rear