Re: Can't compile
Neil Mitchell <ndmitchell <at> gmail.com>
2006-08-03 17:15:11 GMT
> These things don't look quite right
> * Assume that if we're on ppc we're running under OS X.
> (gcc argument)
> - -DPOWERPC_DARWIN
What is your processor and architecture? I'm sure you've said already
but I've forgotten :)
> Prelude.c:(.text+0x11a8): undefined reference to `pow'
> depends/ctypes/libffi/src/prep_cif.o: In function `ffi_prep_cif':
> prep_cif.c:(.text+0x390): undefined reference to `ffi_prep_cif_machdep'
> collect2: ld returned 1 exit status
> scons: *** [inst/bin/yhi] Error 1
> scons: building terminated because of errors.
I remember that Mac seems to auto link against a lot of things, so you
don't need to specify them. I guess if you are not on Mac, then you do
need to specify these. I'll leave Andrew to work out the details...
> Would it be simple to set up a buildbot here? If I find out how, I'll
> probably do that.
If you have buildbot, scons, svn and darcs installed, then setting up
buildbot is a few lines. It would be great if you could be a buildbot,
especially if you have your computer on during the day a few times,
then we can keep tweaking things til we figure out exactly whats going
on. Thats the way we've managed to get Mac PPC working, and it all
seemed very successful.
I know Andrew was going to put up on the wiki a list of instructions
to becoming a buildbot, so hopefully he can do that, and you can set
it up, and we'll get it all working.
> Ok, certainly uniform testing everywhere makes sense. And it would
> obviously add some complexity (and implementation work) to allow to
> replace all uses of libffi with 'error "Foreign function interface
> support not compiled in"', or to have it dynamically possible to be
> available or not, or other "could-be-nice" variations. :)
Personally, I think both libffi and libgmp should be optional - which
for embeded systems reduces dependancies and gives us 100% portable C
with few dependancies (since libpthreads is already defined as
optional). I might see if I can hack this up, in a nicely modular way.
It wasn't that long ago that we didn't have libffi, so the code
probably hasn't diverged that much.
I would guess a nice split is NO_THREADS, NO_FFI, NO_GMP all of which
can be set to 1 to disable them. Currently NO_THREADS is already in
there (but in a very non-modular way).
> Interesting -- I was assuming that Lua was designed to be good at that
> sort of thing (its interpreter can be quite small) -- and GHC binaries
> are infamous for being big, though that will obviously not be the same
> with Yhc. Perhaps Haskell's laziness makes really low memory-use easy in
> some cases.... Looking at Lua's worst memory usage compared to GHC
> (nsieve), it keeps a table for all the numbers up to a maximum! (while
> the haskell version uses arrays and gives ghc lots of strictness to play
> with) Possibly garbage collection is harder with habitual use of tables
> (which go unoptimized -- lua is designed to have a simple
> implementation. Hopefully it isn't ghc's ability to heavily optimize in
> a way we may not be able to :).
GHC is in general more memory heavy, but for certain things, liked
unboxed values, it has an advantage since Yhc can't unbox things. I
guess the only way to know is to run the benchmarks using Yhc :)