Re: [Yhc] Can't compile
Hi Isaac, Your message wasn't sent to the mailing list as well, just me, so I'm forwarding it. Gmail makes it pretty easy to figure out whats happening, but I still don't understand why :) If you can find any docs on mailman that should describe how/why things are working. I have also sent it to our build engineer who will hopefully solve your problem :) Thanks Neil
We've made some tweaks to Yhc, so it might work for you, if it doesn't email us again with lots of exclamation marks :)
If something goes wrong I have a habit of cleanly starting the process from the beginning:
darcs get http://www.cs.york.ac.uk/fp/darcs/yhc-devel cd yhc-devel scons
... gcc -Wall -I. -Idepends/ctypes/libffi/include - -Idepends/ctypes/libffi/src/x86 -Idepends/ctypes/libffi/include - -Idepends/ctypes/libffi/src/powerpc -Idepends/ctypes/libffi -c -o depends/ctypes/libffi/src/cfield.o depends/ctypes/libffi/src/cfield.c In file included from depends/ctypes/libffi/include/ffi.h:63, from depends/ctypes/libffi/src/cfield.c:1: depends/ctypes/libffi/src/x86/ffitarget.h:64: error: 'FFI_DEFAULT_ABI' undeclared here (not in a function) scons: *** [depends/ctypes/libffi/src/cfield.o] Error 1 scons: building terminated because of errors.
!!!!!!!!!!!!!!!!!! ;-) This bit seemingly shouldn't be there: -Idepends/ctypes/libffi/src/x86
By the way, I'm in the middle of upgrading my system to gcc 4.1.1 and glibc 2.4. That doesn't look relevant here though. Also, I removed the useless old strange Gentoo libffi installation (by emerge --unmerge), so that definitely shouldn't be messing anything up now.
Isaac
P.S. the way mailing lists work is confusing me: my best guess is that I should be using "Reply [to] all" but I can't predict the results of that (e.g. was this message sent to the mailing list? I hope so.... and how can I tell if a message I receive was actually sent to the list) I haven't succeeded in finding any sort of "howto use mailing lists" on the web... surely there must be help somewhere for innocent little Thunderbird users who don't know how these things are supposed to work? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEyj0gHgcxvIWYTTURAtQYAJ9LSRNv8UygQ7W37OxcztpCC0dwxgCcDWHp hNHKm/XpjHTB4pdaF2EFG7I= =GPal -----END PGP SIGNATURE-----
Hi Issac, I've just pushed a patch to fix this problem, I'd appreciate it if you could do a darcs pull and try building again. Hopefully it'll get a bit further this time :-) Thanks for your help in testing this, Andrew
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 $ darcs pull $ scons clean #since the same error happened without doing this step $ scons [...] gcc -Wall -I. -Idepends/ctypes/libffi/include - -Idepends/ctypes/libffi/include -Idepends/ctypes/libffi/src/powerpc - -Idepends/ctypes/libffi -c -o depends/ctypes/libffi/src/cfield.o depends/ctypes/libffi/src/cfield.c In file included from depends/ctypes/libffi/include/ffi.h:63, from depends/ctypes/libffi/src/cfield.c:1: depends/ctypes/libffi/src/powerpc/ffitarget.h:72: error: 'FFI_DEFAULT_ABI' undeclared here (not in a function) scons: *** [depends/ctypes/libffi/src/cfield.o] Error 1 scons: building terminated because of errors. Looking in the included file that apparently should define 'FFI_DEFAULT_ABI' (src/runtime/libffi/src/powerpc/ffitarget.h), it looks like it requires 'POWERPC' to be defined, just as the x86 version of that file requires 'X86' to be defined, for it to define 'FFI_DEFAULT_ABI'. In build/ffih/ffi.h it appears to be defined (wrongly [for me]): /* Specify which architecture libffi is configured for. */ #define X86 By the way, these are the relevant symbols that my C preprocessor defines by default. I think 'X86', 'POWERPC', etc. were deliberately chosen so as not to be in this set though. $ echo '' | cpp -dM | grep -i 'ppc\|powerpc' #define __PPC__ 1 #define _ARCH_PPC 1 #define __powerpc__ 1 #define __PPC 1 #define __powerpc 1 #define PPC 1 #define powerpc 1 Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEzfIIHgcxvIWYTTURAkhJAJ4rEPdPfmm54DR8w38N5G48x1ItRgCfSpFZ o5K0z/eJkihTqlk7d5iupc0= =26Q6 -----END PGP SIGNATURE-----
Looking in the included file that apparently should define 'FFI_DEFAULT_ABI' (src/runtime/libffi/src/powerpc/ffitarget.h), it looks like it requires 'POWERPC' to be defined, just as the x86 version of that file requires 'X86' to be defined, for it to define 'FFI_DEFAULT_ABI'. In build/ffih/ffi.h it appears to be defined (wrongly [for me]): /* Specify which architecture libffi is configured for. */ #define X86
I have pushed several patches this afternoon that should (fingers crossed) fix this error, amongst others. If you could try it again that'd be great. Andrew
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Wilkinson wrote:
I have pushed several patches this afternoon that should (fingers crossed) fix this error, amongst others. If you could try it again that'd be great.
It got a little further this time :) Now it looks like it's trying out some x86 assembler: gcc -I. -Idepends/ctypes/libffi/include - -Idepends/ctypes/libffi/src/powerpc -Idepends/ctypes/libffi/include - -Idepends/ctypes/libffi/src/powerpc -Idepends/ctypes/libffi -c -o depends/ctypes/libffi/src/x86/sysv.o depends/ctypes/libffi/src/x86/sysv.S depends/ctypes/libffi/src/x86/sysv.S: Assembler messages: depends/ctypes/libffi/src/x86/sysv.S:42: Error: Unrecognized opcode: `pushl' depends/ctypes/libffi/src/x86/sysv.S:44: Error: Unrecognized opcode: `movl' [... lots more similar errors] scons: *** [depends/ctypes/libffi/src/x86/sysv.o] Error 1 scons: building terminated because of errors. Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEzhYYHgcxvIWYTTURApNrAKConF+ddx1uUFZcA7MnLFDt9rfkNQCfdGkG UWWoY8gqQpdA0cwqewq7Ajc= =qz3P -----END PGP SIGNATURE-----
Excellent, we're getting somewhere. I've pushed another patch to correct that. Unfortunately I'm completly guessing as to which files need to be compiled for libffi to work on ppc platforms. If it doesn't work you could try fiddling with the files listed in /local/d0p6/aw/yhc/build, line 25. The files in that list need to be taken from yhc/depends/ctypes/libffi/src/powerpc (apart from the first two). Andrew
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Wilkinson wrote:
Excellent, we're getting somewhere. I've pushed another patch to correct that.
Unfortunately I'm completly guessing as to which files need to be compiled for libffi to work on ppc platforms.
Now the error is: gcc -I. -Idepends/ctypes/libffi/include - -Idepends/ctypes/libffi/src/powerpc -Idepends/ctypes/libffi/include - -Idepends/ctypes/libffi/src/powerpc -Idepends/ctypes/libffi -c -o depends/ctypes/libffi/src/powerpc/sysv.o depends/ctypes/libffi/src/powerpc/sysv.S depends/ctypes/libffi/src/powerpc/sysv.S:29:25: error: powerpc/asm.h: No such file or directory scons: *** [depends/ctypes/libffi/src/powerpc/sysv.o] Error 1 scons: building terminated because of errors. There is a depends/ctypes/libffi/src/powerpc/asm.h that I assume it's trying to include, (also there is src/runtime/libffi/src/powerpc/asm.h ...), hmm...
If it doesn't work you could try fiddling with the files listed in /local/d0p6/aw/yhc/build, line 25. The files in that list need to be taken from yhc/depends/ctypes/libffi/src/powerpc (apart from the first two).
I can't find whatever file "/local/d0p6/aw/yhc/build" you're referring to... What is Yhc doing that depends on the machine architecture? Is all this ctypes, libffi, endianness testing, etc, just for the Haskell Foreign Function Interface? Maybe it would help if I understood the organization of these platform-specific things (if there is any yet). (speculation) : Maybe it would be good to separate them out into one place so that it's easy to see where any such thing occurs, and check that (if things need to be split into cases by architecture) all supported cases are covered. It would be nice to be able to build the completely-portable parts of Yhc (i.e. everything but the FFI) without relying on anything but a bytecode interpreter (ANSI C compiler for usual Yhc bytecode interpreter, .NET, whatever). Then we could be at least as portable as Lua, though maybe not as memory-efficient. :) (And I could test the parts of Yhc that do work for me.) Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEzjJCHgcxvIWYTTURArHvAJsGSd5EsJ4yyB+d/HRCSkh3Byd5fQCfTltZ 7yLuprOydmJifhELnWhLvAo= =WEmd -----END PGP SIGNATURE-----
Hi Isaac, Me and Andrew have spent some time playing, and our buildbot for Yhc with Mac OS X PPC gets to the end, and passes almost all of the tests (one failing, which we're still tracking down). Could you have another go at compiling, and let us know if you are successful? Re: separating out the build, there are some issues with that. The main one is that its simplest if the internal functions are invoked in exactly the same way as the external ones - this results in less special cases and better testing for everything. But this of course means depending on libffi for the internal functions as well. Fortunately libffi is available almost everywhere, at least everywhere Python is available, so isn't a major problem. You also refer to "better memory use" compared to Lua? Given the following graph: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua&lang2=ghc It seems that GHC has better memory use than Lua in most of the tests, and in general Yhc has better memory use than GHC, so (taking a wild guess), Yhc should be less memory intensive than Lua. Thanks Neil
What is Yhc doing that depends on the machine architecture? Is all this ctypes, libffi, endianness testing, etc, just for the Haskell Foreign Function Interface? Maybe it would help if I understood the organization of these platform-specific things (if there is any yet). (speculation) : Maybe it would be good to separate them out into one place so that it's easy to see where any such thing occurs, and check that (if things need to be split into cases by architecture) all supported cases are covered. It would be nice to be able to build the completely-portable parts of Yhc (i.e. everything but the FFI) without relying on anything but a bytecode interpreter (ANSI C compiler for usual Yhc bytecode interpreter, .NET, whatever). Then we could be at least as portable as Lua, though maybe not as memory-efficient. :) (And I could test the parts of Yhc that do work for me.)
Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEzjJCHgcxvIWYTTURArHvAJsGSd5EsJ4yyB+d/HRCSkh3Byd5fQCfTltZ 7yLuprOydmJifhELnWhLvAo= =WEmd -----END PGP SIGNATURE----- _______________________________________________ Yhc mailing list Yhc@haskell.org http://www.haskell.org//mailman/listinfo/yhc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Neil Mitchell wrote:
Hi Isaac,
Me and Andrew have spent some time playing, and our buildbot for Yhc with Mac OS X PPC gets to the end, and passes almost all of the tests (one failing, which we're still tracking down).
Could you have another go at compiling, and let us know if you are successful?
These things don't look quite right (patch) * Assume that if we're on ppc we're running under OS X. (gcc argument) - -DPOWERPC_DARWIN But I got the same errors when I specifically didn't include the suspiciously-named patches (hooray for darcs' flexibility) : gcc -o inst/bin/yhi src/runtime/BCKernel/external.o src/runtime/BCKernel/hashtable.o src/runtime/BCKernel/heap.o src/runtime/BCKernel/hsffi.o src/runtime/BCKernel/info.o src/runtime/BCKernel/integer.o src/runtime/BCKernel/iofuncs.o src/runtime/BCKernel/jonkers.o src/runtime/BCKernel/main.o src/runtime/BCKernel/make.o src/runtime/BCKernel/mark.o src/runtime/BCKernel/module.o src/runtime/BCKernel/mutator.o src/runtime/BCKernel/pretty.o src/runtime/BCKernel/primitive.o src/runtime/BCKernel/sanity.o src/runtime/BCKernel/stopcopy.o src/runtime/BCKernel/profile.o src/runtime/BCKernel/foreign.o src/runtime/BCKernel/process.o src/runtime/BCKernel/thread.o src/runtime/BCKernel/stable.o src/runtime/BCKernel/builtin/Concurrent.o src/runtime/BCKernel/builtin/Array.o src/runtime/BCKernel/builtin/FFI.o src/runtime/BCKernel/builtin/IO.o src/runtime/BCKernel/builtin/Prelude.o src/runtime/BCKernel/builtin/PackedString.o src/runtime/BCKernel/builtin/RuntimeAPI.o src/runtime/BCKernel/builtin/System.o depends/ctypes/libffi/src/prep_cif.o depends/ctypes/libffi/src/cfield.o depends/ctypes/libffi/src/powerpc/ffi_darwin.o depends/ctypes/libffi/src/powerpc/darwin.o depends/ctypes/libffi/src/powerpc/darwin_closure.o -lgmp src/runtime/BCKernel/external.o: In function `dll_open': external.c:(.text+0x31c): undefined reference to `dlopen' src/runtime/BCKernel/external.o: In function `dll_sym': external.c:(.text+0x364): undefined reference to `dlsym' src/runtime/BCKernel/external.o: In function `dll_error': external.c:(.text+0x39c): undefined reference to `dlerror' src/runtime/BCKernel/hsffi.o: In function `hsffi_call': hsffi.c:(.text+0x5b4): undefined reference to `ffi_call' src/runtime/BCKernel/hsffi.o: In function `hsffi_evalContext': hsffi.c:(.text+0x67c): undefined reference to `ffi_call' src/runtime/BCKernel/thread.o: In function `osthread_create': thread.c:(.text+0x2b0): undefined reference to `pthread_create' src/runtime/BCKernel/thread.o: In function `yhi_semaphore_create': thread.c:(.text+0x4a4): undefined reference to `sem_init' thread.c:(.text+0x51c): undefined reference to `sem_open' thread.c:(.text+0x530): undefined reference to `sem_unlink' src/runtime/BCKernel/thread.o: In function `yhi_semaphore_signal': thread.c:(.text+0x5c8): undefined reference to `sem_post' src/runtime/BCKernel/thread.o: In function `yhi_semaphore_wait': thread.c:(.text+0x634): undefined reference to `sem_wait' src/runtime/BCKernel/thread.o: In function `yhi_semaphore_zero': thread.c:(.text+0x6a0): undefined reference to `sem_trywait' src/runtime/BCKernel/thread.o: In function `yhi_semaphore_destroy': thread.c:(.text+0x6f4): undefined reference to `sem_destroy' thread.c:(.text+0x710): undefined reference to `sem_close' src/runtime/BCKernel/builtin/Prelude.o: In function `_primFloatExp': Prelude.c:(.text+0x308): undefined reference to `exp' src/runtime/BCKernel/builtin/Prelude.o: In function `_primFloatLog': Prelude.c:(.text+0x390): undefined reference to `log' src/runtime/BCKernel/builtin/Prelude.o: In function `_primFloatSqrt': Prelude.c:(.text+0x418): undefined reference to `sqrt' src/runtime/BCKernel/builtin/Prelude.o: In function `_primFloatSin': Prelude.c:(.text+0x4a0): undefined reference to `sin' src/runtime/BCKernel/builtin/Prelude.o: In function `_primFloatCos': Prelude.c:(.text+0x528): undefined reference to `cos' src/runtime/BCKernel/builtin/Prelude.o: In function `_primFloatTan': Prelude.c:(.text+0x5b0): undefined reference to `tan' src/runtime/BCKernel/builtin/Prelude.o: In function `_primFloatASin': Prelude.c:(.text+0x638): undefined reference to `asin' src/runtime/BCKernel/builtin/Prelude.o: In function `_primFloatACos': Prelude.c:(.text+0x6c0): undefined reference to `acos' src/runtime/BCKernel/builtin/Prelude.o: In function `_primFloatATan': Prelude.c:(.text+0x748): undefined reference to `atan' src/runtime/BCKernel/builtin/Prelude.o: In function `_primFloatPow': Prelude.c:(.text+0x810): undefined reference to `pow' src/runtime/BCKernel/builtin/Prelude.o: In function `_primDoubleExp': Prelude.c:(.text+0xcc8): undefined reference to `exp' src/runtime/BCKernel/builtin/Prelude.o: In function `_primDoubleLog': Prelude.c:(.text+0xd4c): undefined reference to `log' src/runtime/BCKernel/builtin/Prelude.o: In function `_primDoubleSqrt': Prelude.c:(.text+0xdd0): undefined reference to `sqrt' src/runtime/BCKernel/builtin/Prelude.o: In function `_primDoubleSin': Prelude.c:(.text+0xe54): undefined reference to `sin' src/runtime/BCKernel/builtin/Prelude.o: In function `_primDoubleCos': Prelude.c:(.text+0xed8): undefined reference to `cos' src/runtime/BCKernel/builtin/Prelude.o: In function `_primDoubleTan': Prelude.c:(.text+0xf5c): undefined reference to `tan' src/runtime/BCKernel/builtin/Prelude.o: In function `_primDoubleASin': Prelude.c:(.text+0xfe0): undefined reference to `asin' src/runtime/BCKernel/builtin/Prelude.o: In function `_primDoubleACos': Prelude.c:(.text+0x1064): undefined reference to `acos' src/runtime/BCKernel/builtin/Prelude.o: In function `_primDoubleATan': Prelude.c:(.text+0x10e8): undefined reference to `atan' src/runtime/BCKernel/builtin/Prelude.o: In function `_primDoublePow': 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. Adding "m" and "dl" to the list of libraries made some of the errors go away but I didn't know where the other references are supposed to be defined. Would it be simple to set up a buildbot here? If I find out how, I'll probably do that.
Re: separating out the build, there are some issues with that. The main one is that its simplest if the internal functions are invoked in exactly the same way as the external ones - this results in less special cases and better testing for everything. But this of course means depending on libffi for the internal functions as well. Fortunately libffi is available almost everywhere, at least everywhere Python is available, so isn't a major problem.
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. :)
You also refer to "better memory use" compared to Lua? Given the following graph: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua&lang2=ghc
It seems that GHC has better memory use than Lua in most of the tests, and in general Yhc has better memory use than GHC, so (taking a wild guess), Yhc should be less memory intensive than Lua.
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 :). Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE0hx+HgcxvIWYTTURAuVzAJkB/TBob4iPNIvJphOdugwLcDTjkQCfS8zQ 5O6m6oLK3tobrJ3JYCRZVos= =2bBi -----END PGP SIGNATURE-----
Hi Isaac,
These things don't look quite right (patch) * 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.
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
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. 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 :)
Thanks Neil
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Neil Mitchell wrote:
Hi Isaac,
These things don't look quite right (patch) * 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 :)
powerpc linux; specifically, at the moment, $ uname -a Linux moa 2.6.17-gentoo-r3 #3 Mon Jul 17 06:43:18 EDT 2006 ppc 740/750 GNU/Linux
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.
Okay, first step is to install buildbot anyway. :) Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE0jVzHgcxvIWYTTURApw/AKChy+fKani1GR/q/9pXqjZJOAm69wCfUh81 LCVobZC4Umlx5qvottkLnP8= =HkSa -----END PGP SIGNATURE-----
Hi, Issac, Sorry for the delay in getting this done. Can you pull *all* the patches and give it another try? If I've selected the right files to build in libffi it should work now. Cheers, Andrew
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Wilkinson wrote:
Hi, Issac,
Sorry for the delay in getting this done. Can you pull *all* the patches and give it another try?
Be warned, something funky happened in my gentoo installation and I switched to Ubuntu :) (same hardware, and running a gentoo kernel until I can make it boot successfully with an official ubuntu one) (ubuntu has a buildbot package in "universe" too, so that'll be convenient) $ darcs get http://www.cs.york.ac.uk/fp/darcs/yhc-devel $ scons [... all good here] gcc -I. -I/usr/local/include -Idepends/ctypes/libffi/include - -Idepends/ctypes/libffi/src/powerpc -Idepends/ctypes/libffi/include - -Idepends/ctypes/libffi/src -Idepends/ctypes/libffi/src/powerpc - -Idepends/ctypes/libffi -c -o depends/ctypes/libffi/src/x86/sysv.o depends/ctypes/libffi/src/x86/sysv.S depends/ctypes/libffi/src/x86/sysv.S: Assembler messages: depends/ctypes/libffi/src/x86/sysv.S:42: Error: Unrecognized opcode: `pushl' depends/ctypes/libffi/src/x86/sysv.S:44: Error: Unrecognized opcode: `movl' [... lots more similar errors] scons: *** [depends/ctypes/libffi/src/x86/sysv.o] Error 1 scons: building terminated because of errors. Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE2hV2HgcxvIWYTTURAnYBAKCD1Rum58+/faMZNU8g+Bp6n2nmzwCdHbaE 4fg+p9+5h5btdTxrjwVd+pU= =TpeW -----END PGP SIGNATURE-----
On 8/9/06, Isaac
Be warned, something funky happened in my gentoo installation and I switched to Ubuntu :) (same hardware, and running a gentoo kernel until I can make it boot successfully with an official ubuntu one) (ubuntu has a buildbot package in "universe" too, so that'll be convenient)
$ darcs get http://www.cs.york.ac.uk/fp/darcs/yhc-devel $ scons [... all good here] gcc -I. -I/usr/local/include -Idepends/ctypes/libffi/include - -Idepends/ctypes/libffi/src/powerpc -Idepends/ctypes/libffi/include - -Idepends/ctypes/libffi/src -Idepends/ctypes/libffi/src/powerpc - -Idepends/ctypes/libffi -c -o depends/ctypes/libffi/src/x86/sysv.o depends/ctypes/libffi/src/x86/sysv.S depends/ctypes/libffi/src/x86/sysv.S: Assembler messages: depends/ctypes/libffi/src/x86/sysv.S:42: Error: Unrecognized opcode: `pushl' depends/ctypes/libffi/src/x86/sysv.S:44: Error: Unrecognized opcode: `movl' [... lots more similar errors] scons: *** [depends/ctypes/libffi/src/x86/sysv.o] Error 1 scons: building terminated because of errors.
Oops. that's a silly copy and paste error on my part. Fixed now :-) Please try again. Andrew
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Much more successful this time, and then... gcc -o inst/bin/yhi src/runtime/BCKernel/external.o src/runtime/BCKernel/hashtable.o src/runtime/BCKernel/heap.o src/runtime/BCKernel/hsffi.o src/runtime/BCKernel/info.o src/runtime/BCKernel/integer.o src/runtime/BCKernel/iofuncs.o src/runtime/BCKernel/jonkers.o src/runtime/BCKernel/main.o src/runtime/BCKernel/make.o src/runtime/BCKernel/mark.o src/runtime/BCKernel/module.o src/runtime/BCKernel/mutator.o src/runtime/BCKernel/pretty.o src/runtime/BCKernel/primitive.o src/runtime/BCKernel/sanity.o src/runtime/BCKernel/stopcopy.o src/runtime/BCKernel/profile.o src/runtime/BCKernel/foreign.o src/runtime/BCKernel/process.o src/runtime/BCKernel/thread.o src/runtime/BCKernel/stable.o src/runtime/BCKernel/builtin/Concurrent.o src/runtime/BCKernel/builtin/Array.o src/runtime/BCKernel/builtin/FFI.o src/runtime/BCKernel/builtin/IO.o src/runtime/BCKernel/builtin/Prelude.o src/runtime/BCKernel/builtin/PackedString.o src/runtime/BCKernel/builtin/RuntimeAPI.o src/runtime/BCKernel/builtin/System.o depends/ctypes/libffi/src/prep_cif.o depends/ctypes/libffi/src/cfield.o depends/ctypes/libffi/src/powerpc/ffi.o depends/ctypes/libffi/src/powerpc/ppc_closure.o depends/ctypes/libffi/src/powerpc/sysv.o -L/usr/local/lib -lgmp src/runtime/BCKernel/external.o: In function `dll_open':external.c:(.text+0x314): undefined reference to `dlopen'src/runtime/BCKernel/external.o: In function `dll_sym':external.c:(.text+0x35c): undefined reference to `dlsym' src/runtime/BCKernel/external.o: In function `dll_error':external.c:(.text+0x394): undefined reference to `dlerror' src/runtime/BCKernel/thread.o: In function `osthread_create':thread.c:(.text+0x2b0): undefined reference to `pthread_create' src/runtime/BCKernel/thread.o: In function `yhi_semaphore_create':thread.c:(.text+0x4ac): undefined reference to `sem_init' :thread.c:(.text+0x528): undefined reference to `sem_open' :thread.c:(.text+0x53c): undefined reference to `sem_unlink' src/runtime/BCKernel/thread.o: In function `yhi_semaphore_signal':thread.c:(.text+0x5d4): undefined reference to `sem_post' src/runtime/BCKernel/thread.o: In function `yhi_semaphore_wait':thread.c:(.text+0x640): undefined reference to `sem_wait' src/runtime/BCKernel/thread.o: In function `yhi_semaphore_zero':thread.c:(.text+0x6ac): undefined reference to `sem_trywait' src/runtime/BCKernel/thread.o: In function `yhi_semaphore_destroy':thread.c:(.text+0x700): undefined reference to `sem_destroy' :thread.c:(.text+0x71c): undefined reference to `sem_close' src/runtime/BCKernel/builtin/Prelude.o: In function `_primFloatExp':Prelude.c:(.text+0x308): undefined reference to `exp' src/runtime/BCKernel/builtin/Prelude.o: In function `_primFloatLog':Prelude.c:(.text+0x390): undefined reference to `log' src/runtime/BCKernel/builtin/Prelude.o: In function `_primFloatSqrt':Prelude.c:(.text+0x418): undefined reference to `sqrt' src/runtime/BCKernel/builtin/Prelude.o: In function `_primFloatSin':Prelude.c:(.text+0x4a0): undefined reference to `sin' src/runtime/BCKernel/builtin/Prelude.o: In function `_primFloatCos':Prelude.c:(.text+0x528): undefined reference to `cos' src/runtime/BCKernel/builtin/Prelude.o: In function `_primFloatTan':Prelude.c:(.text+0x5b0): undefined reference to `tan' src/runtime/BCKernel/builtin/Prelude.o: In function `_primFloatASin':Prelude.c:(.text+0x638): undefined reference to `asin' src/runtime/BCKernel/builtin/Prelude.o: In function `_primFloatACos':Prelude.c:(.text+0x6c0): undefined reference to `acos' src/runtime/BCKernel/builtin/Prelude.o: In function `_primFloatATan':Prelude.c:(.text+0x748): undefined reference to `atan' src/runtime/BCKernel/builtin/Prelude.o: In function `_primFloatPow':Prelude.c:(.text+0x810): undefined reference to `pow' src/runtime/BCKernel/builtin/Prelude.o: In function `_primDoubleExp':Prelude.c:(.text+0xcd4): undefined reference to `exp' src/runtime/BCKernel/builtin/Prelude.o: In function `_primDoubleLog':Prelude.c:(.text+0xd58): undefined reference to `log' src/runtime/BCKernel/builtin/Prelude.o: In function `_primDoubleSqrt':Prelude.c:(.text+0xddc): undefined reference to `sqrt' src/runtime/BCKernel/builtin/Prelude.o: In function `_primDoubleSin':Prelude.c:(.text+0xe60): undefined reference to `sin' src/runtime/BCKernel/builtin/Prelude.o: In function `_primDoubleCos':Prelude.c:(.text+0xee4): undefined reference to `cos' src/runtime/BCKernel/builtin/Prelude.o: In function `_primDoubleTan':Prelude.c:(.text+0xf68): undefined reference to `tan' src/runtime/BCKernel/builtin/Prelude.o: In function `_primDoubleASin':Prelude.c:(.text+0xfec): undefined reference to `asin' src/runtime/BCKernel/builtin/Prelude.o: In function `_primDoubleACos':Prelude.c:(.text+0x1070): undefined reference to `acos' src/runtime/BCKernel/builtin/Prelude.o: In function `_primDoubleATan':Prelude.c:(.text+0x10f4): undefined reference to `atan' src/runtime/BCKernel/builtin/Prelude.o: In function `_primDoublePow':Prelude.c:(.text+0x11b4): undefined reference to `pow' collect2: ld returned 1 exit status scons: *** [inst/bin/yhi] Error 1 scons: building terminated because of errors. Adding -lm -lpthread -ldl to that command causes it to succeed -- I suppose the scons stuff should link in those libraries in the appropriate way. Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE2xAfHgcxvIWYTTURAiUqAKDKV7GHdoGxtk8uKsWasIACyUg5FACgjjJd b39pydzGBFQcp0FmA244syw= =Qwlx -----END PGP SIGNATURE-----
On 8/10/06, Isaac
Adding -lm -lpthread -ldl to that command causes it to succeed -- I suppose the scons stuff should link in those libraries in the appropriate way.
That's left over from trying to get it to work on MacOS. For some reason it was automatically linking with libraries then. I've pushed another patch. Does this mean the whole thing now builds correctly? What happens when you type 'scons test'? Cheers, Andrew
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Wilkinson wrote:
Does this mean the whole thing now builds correctly? What happens when you type 'scons test'?
Summary: Yhc built but didn't pass all the tests. I noticed this warning appearing a couple times while building Yhc: Warning: The module PreludeBuiltin is called Prelude in its interface file (inst/lib/yhc/packages/yhc-base/1.0/PreludeBuiltin.hi) Also some warnings here: Compiling YHC.Internal ( src/packages/yhc-base-1.0/YHC/Internal.hs ) Warning: _apply1 is both imported and defined Warning: _apply2 is both imported and defined Warning: _apply3 is both imported and defined Warning: _apply4 is both imported and defined Warning: _id is both imported and defined Warning: _eqInteger is both imported and defined Warning: _eqFloat is both imported and defined Warning: _eqDouble is both imported and defined Warning: IO is both imported and defined Following is the test output. My computer has a minor habit of crashing compilers randomly (segfault or illegal instruction -- by now it's happened with gcc 3.3-OSX, gcc-3.4.4, 4.0.3, and 4.1.1, and ghc has randomly segfaulted too, especially when my whole computer's memory usage was high... but "memtester" running for several hours didn't find anything, and it doesn't usually happen very often) so it might be its fault of compiling yhc incorrectly rather than just compiler-crashing... and it takes quite a while for ghc+gcc to compile Yhc here on this old computer, so I don't feel like doing it again (if I had instructions to set up buildbot then I wouldn't need to feel like doing it again, I could just set it up as a "nice", automated process in the background...) Maybe the test output shouldn't (ever) include nonprinting characters? - -- TEST ( 1/52) - Array/timeLargeArray ERROR: different stdout EXPECTED: 11 ACTUAL: ERROR: different stderr EXPECTED: ACTUAL: Module Prelude is corrupt! Const table entry 3 is ''[0x02] in function Prelude.Num.Prelude.Integer.signum - -- TEST ( 2/52) - Emptydecls - -- TEST ( 3/52) - Enum/list ERROR: different stdout EXPECTED: [1 % 1] ACTUAL: ERROR: different stderr EXPECTED: ACTUAL: Module Prelude is corrupt! Const table entry 3 is ''[0x02] in function Prelude.Num.Prelude.Integer.signum - -- TEST ( 4/52) - Enum/succ ERROR: different stdout EXPECTED: 1.0e20 ACTUAL: ERROR: different stderr EXPECTED: ACTUAL: Module Prelude is corrupt! Const table entry 3 is ''[0x02] in function Prelude.Num.Prelude.Integer.signum - -- TEST ( 5/52) - IO/overwrite - -- TEST ( 6/52) - Misc/wolfram ERROR: different stdout EXPECTED: [1.0,3.0,5.0,7.0,9.0,11.0,13.0,19.0] ACTUAL: ERROR: different stderr EXPECTED: ACTUAL: Module Prelude is corrupt! Const table entry 3 is ''[0x02] in function Prelude.Num.Prelude.Integer.signum - -- TEST ( 7/52) - NewType - -- TEST ( 8/52) - Queens - -- TEST ( 9/52) - chr - -- TEST (10/52) - lex - -- TEST (11/52) - parsing/literate - -- TEST (12/52) - ctxsimpl - -- TEST (13/52) - ctxsimpl/bad - -- TEST (14/52) - fields/empty - -- TEST (15/52) - fields/operator ERROR: different stdout EXPECTED: Hash{(#)=3} Hash{(#)=3} ACTUAL: ERROR: different stderr EXPECTED: ACTUAL: Module Prelude is corrupt! Const table entry 3 is ''[0x02] in function Prelude.Num.Prelude.Integer.signum - -- TEST (16/52) - fields/showread ERROR: different stdout EXPECTED: (Foo{foo=1,bar=99},Foo{foo=(),bar=99},Foo{foo=True,bar=99}) (Foo{foo=1,bar=99},Foo{foo=(),bar=99},Foo{foo=True,bar=99}) ACTUAL: ERROR: different stderr EXPECTED: ACTUAL: Module Prelude is corrupt! Const table entry 3 is ''[0x02] in function Prelude.Num.Prelude.Integer.signum - -- TEST (17/52) - fields/type - -- TEST (18/52) - identifiers/qual - -- TEST (19/52) - identifiers/twiddle - -- TEST (20/52) - importas - -- TEST (21/52) - infix/constructor - -- TEST (22/52) - infix/derived - -- TEST (23/52) - infix/fndecl - -- TEST (24/52) - infix/infix - -- TEST (25/52) - infix/local ERROR: different stdout EXPECTED: 11 ACTUAL: ERROR: different stderr EXPECTED: ACTUAL: Module Prelude is corrupt! Const table entry 3 is ''[0x02] in function Prelude.Num.Prelude.Integer.signum - -- TEST (26/52) - infix/minus ERROR: different stdout EXPECTED: - -12 ACTUAL: ERROR: different stderr EXPECTED: ACTUAL: Module Main is corrupt! Const table entry 1 is '?'[0x255] in function f - -- TEST (27/52) - infix/operator ERROR: different stdout EXPECTED: [3] ACTUAL: ERROR: different stderr EXPECTED: ACTUAL: Module Prelude is corrupt! Const table entry 3 is ''[0x02] in function Prelude.Num.Prelude.Integer.signum - -- TEST (28/52) - layout/bad - -- TEST (29/52) - layout/case - -- TEST (30/52) - layout/brace - -- TEST (31/52) - layout/do - -- TEST (32/52) - layout/indent - -- TEST (33/52) - layout/layout - -- TEST (34/52) - layout/rightbrace - -- TEST (35/52) - layout/tullsen1 - -- TEST (36/52) - layout/tullsen2 ERROR: different stdout EXPECTED: 6 ACTUAL: ERROR: different stderr EXPECTED: ACTUAL: Module Prelude is corrupt! Const table entry 3 is ''[0x02] in function Prelude.Num.Prelude.Integer.signum - -- TEST (37/52) - layout/whitespace ERROR: different stdout EXPECTED: True ACTUAL: ERROR: different stderr EXPECTED: ACTUAL: Module Prelude is corrupt! Const table entry 3 is ''[0x02] in function Prelude.Num.Prelude.Integer.signum - -- TEST (38/52) - listindex - -- TEST (39/52) - maintype - -- TEST (40/52) - numbers/floatdouble ERROR: different stdout EXPECTED: (0.12345679,0.12345678912345678) ACTUAL: ERROR: different stderr EXPECTED: ACTUAL: Module Prelude is corrupt! Const table entry 3 is ''[0x02] in function Prelude.Num.Prelude.Integer.signum - -- TEST (41/52) - numbers/integerdouble ERROR: different stdout EXPECTED: 1.23456789e8 ACTUAL: ERROR: different stderr EXPECTED: ACTUAL: Module Prelude is corrupt! Const table entry 3 is ''[0x02] in function Prelude.Num.Prelude.Integer.signum - -- TEST (42/52) - numbers/negliteral ERROR: different stdout EXPECTED: (Negate (FromInteger 2),True) ACTUAL: ERROR: different stderr EXPECTED: ACTUAL: Module Prelude is corrupt! Const table entry 3 is ''[0x02] in function Prelude.Num.Prelude.Integer.signum - -- TEST (43/52) - numbers/subtract ERROR: different stdout EXPECTED: (0.70470005,0.7047) ACTUAL: ERROR: different stderr EXPECTED: ACTUAL: Module Prelude is corrupt! Const table entry 3 is ''[0x02] in function Prelude.Num.Prelude.Integer.signum - -- TEST (44/52) - qualifiers - -- TEST (45/52) - read/1x23 ERROR: different stdout EXPECTED: [(1,"x23")] ACTUAL: ERROR: different stderr EXPECTED: ACTUAL: Module Prelude is corrupt! Const table entry 3 is ''[0x02] in function Prelude.Num.Prelude.Integer.signum - -- TEST (46/52) - read/readex - -- TEST (47/52) - read/singleconstr - -- TEST (48/52) - self-print - -- TEST (49/52) - semicolon - -- TEST (50/52) - strings/newline - -- TEST (51/52) - getargs - -- TEST (52/52) - packedstring ERROR: different stdout EXPECTED: This is string B ACTUAL: - -- SUMMARY Passed: 35 Failed: 17 Total : 52 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE2x0qHgcxvIWYTTURAo70AJ97lN5oHzwpvBG5TdiVAzyFwq9SOQCeJxXl Lm4tRJPwEXJ4D+QJQpYjEr0= =PAqD -----END PGP SIGNATURE-----
Those errors are beyond my knowlege of Yhc so I'll have to leave that to
Neil and Tom to fix :-) I do know that compiling the library always produces
a load of error messages.
On 8/10/06, Isaac
(if I had instructions to set up buildbot then I wouldn't need to feel like doing it again, I could just set it up as a "nice", automated process in the background...)
I have written some instructions on how to become a buildbot slave - http://www.haskell.org/haskellwiki/Yhc/Buildbot I'll email you away from the list with a username and password. Cheers, Andrew
participants (3)
-
Andrew Wilkinson -
Isaac -
Neil Mitchell