Re: Snow Leopard GHC
Latest set of problems. I've tried using the i386 build of GHC 6.10.4 to build the x86_64 version in the manner that I described in an earlier post. I'm not getting any segfaults now, but instead it says the following during make: /Users/bjs/Desktop/GHC_Build/ghc-6.10.4/libraries/cabal-bin /usr/bin/ ghc /Users/bjs/Desktop/GHC_Build/ghc-6.10.4/libraries/ bootstrapping.conf 1.6.0.3 build --distpref dist-install --ghc- option=-H32m --ghc-option=-O --ghc-option=-I/sw/include --ghc-option=- L/sw/lib --ghc-option=-Wall Preprocessing executables for installPackage-1.0... Building installPackage-1.0... [1 of 1] Compiling Main ( installPackage.hs, dist-install/ build/installPackage/installPackage-tmp/Main.o ) /var/folders/IZ/IZ09PkvEHBmw7qmXrvZvFE+++TI/-Tmp-/ghc38027_0/ ghc38027_0.s:3616:0: Bignum number illegal. Absolute 0 assumed. /var/folders/IZ/IZ09PkvEHBmw7qmXrvZvFE+++TI/-Tmp-/ghc38027_0/ ghc38027_0.s:3677:0: Bignum number illegal. Absolute 0 assumed. /var/folders/IZ/IZ09PkvEHBmw7qmXrvZvFE+++TI/-Tmp-/ghc38027_0/ ghc38027_0.s:3709:0: Bignum number illegal. Absolute 0 assumed. etc... Looking in the assembler file, I get stuff like: Lc4a1: jmp *-16(%r13) .long _s3j4_info - _s3j4_info_dsp .text .align 3 _s3lv_info_dsp: .quad _Main_a1_srt-(_s3lv_info)+72 .quad 3 .quad 375900174587920 _s3lv_info: Lc4bb: leaq -16(%rbp),%rax cmpq %r14,%rax (That bignum is at line 3616.) Any ideas what might be causing this? Cheers, Barney. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Snow Leopard GHC
So which compiler is generating the bogus code here? Is this the stage1 x86-64 compiler, or the i386 compiler? It's the stage1 x86_64 compiler. The problem here is that 375900174587920 doesn't even fit into 64 bits, hence the assembler's complaint. Cheers, Barney. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Snow Leopard GHC
On 08/10/2009 15:07, Barney Stratford wrote: So which compiler is generating the bogus code here? Is this the stage1 x86-64 compiler, or the i386 compiler? It's the stage1 x86_64 compiler. The problem here is that 375900174587920 doesn't even fit into 64 bits, hence the assembler's complaint. Yes, I see that. GHC keeps these values as Integers internally, so it's possible that some misconfiguration has caused it to produce a values that's out of range, although I agree that the fact that it is bigger than even 2^64 is quite suspicious. I suggest dumping out some intermediate code, e.g. -dppr-cmm -dppr-opt-cmm. If that fails to narrow it down, then you may need to add some debug traces the native code generator to find out where these values are coming from. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Snow Leopard GHC
I am happy to take care of funnelling Barney's changes into the main repo. However, I think there was at least one more mentioned in another email. The other change is already in the repo. That's where I borrowed it from in the first place. Barney. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Snow Leopard GHC
Simon Marlow: On 24/09/2009 23:54, Barney Stratford wrote: I've tried just letting the dynamic linker (dyld) sort everything out for us, but this failed because not all symbols are dynamically linked, and the statically linked ones are invisible to it. One change that will be necessary in any case: towards the end of rts/Linker.c, change case X86_64_RELOC_SIGNED: ASSERT(reloc-r_pcrel); thing += value - baseValue; break; to case X86_64_RELOC_SIGNED: case X86_64_RELOC_SIGNED_1: case X86_64_RELOC_SIGNED_2: case X86_64_RELOC_SIGNED_4: ASSERT(reloc-r_pcrel); thing += value - baseValue; break; Manuel, maybe you could validate and push this one? I am happy to take care of funnelling Barney's changes into the main repo. However, I think there was at least one more mentioned in another email. Barney, do you have a comprehensive set of the changes that you made (ideally against the HEAD repo, or a nightly snapshot, but if that's difficult, then against 6.10)? And did you try to run the testsuite http://darcs.haskel.org/testsuite with the compiler that you generated? Manuel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Snow Leopard GHC
On 24/09/2009 23:54, Barney Stratford wrote: Only limited success with GHCi, I'm afraid. The problem seems to be that Snow Leopard is much stricter about security than Leopard was. (Caveat - I don't really know what I'm talking about.) In particular, I don't think it will let you execute code outside of the __TEXT segment, which is exactly what GHCi tries to do - hence the bus errors. We had similar problems with SELinux, which we worked around by using libffi to allocate our memory; it handles the multiple-mmapping trick that you need to do to avoid having memory that is both writable and executable. You might need to enable this for Darwin too: look in rts/sm/Storage.c:allocateExec(), and change the #ifdef so that the libffi version is used for darwin too. I've tried just letting the dynamic linker (dyld) sort everything out for us, but this failed because not all symbols are dynamically linked, and the statically linked ones are invisible to it. One change that will be necessary in any case: towards the end of rts/Linker.c, change case X86_64_RELOC_SIGNED: ASSERT(reloc-r_pcrel); thing += value - baseValue; break; to case X86_64_RELOC_SIGNED: case X86_64_RELOC_SIGNED_1: case X86_64_RELOC_SIGNED_2: case X86_64_RELOC_SIGNED_4: ASSERT(reloc-r_pcrel); thing += value - baseValue; break; Manuel, maybe you could validate and push this one? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Snow Leopard GHC
OK, I'm trying to get a more-recent GHC working that has that #ifdef that you mentioned. Specifically, 6.10.4. I've said: ./configure --build=x86_64-apple-darwin --host=x86_64-apple-darwin -- target=x86_64-apple-darwin --with-gmp-includes='/sw/include' --with- gmp-libraries='/sw/lib' make and it fails, saying it can't find libgmp, even though I've just told it where gmp is. I've copied my mk/build.mk straight from my 6.8.3 build, and it says ReadlineIncludePath=/sw/include SRC_CC_OPTS += -I/sw/include -L/sw/lib SRC_HC_OPTS += -I/sw/include -L/sw/lib EXTRA_HSC2HS_OPTS += -I/sw/include EXTRA_LD_OPTS += -L/sw/lib The resulting error message is: [51 of 51] Compiling Distribution.Simple ( Distribution/Simple.hs, dist-bootstrapping/build/Distribution/Simple.o ) ar: creating archive dist-bootstrapping/build/libHSCabal-1.6.0.3.a cd Cabal /Users/bjs/Desktop/GHC_Build/ghc-6.10.4/libraries/cabal- bin /Users/bjs/Desktop/GHC_Build/install/bin/ghc /Users/bjs/Desktop/ GHC_Build/ghc-6.10.4/libraries/bootstrapping.conf 1.6.0.3 install -- distpref=dist-bootstrapping --inplace Installing library in /Users/bjs/Desktop/GHC_Build/ghc-6.10.4/libraries/Cabal/dist- bootstrapping/install/usr/local/lib/Cabal-1.6.0.3/ghc-6.8.3 Registering Cabal-1.6.0.3... Reading package info from dist-bootstrapping/inplace-pkg-config ... done. Saving old package config file... done. Writing new package config file... done. cd hpc /Users/bjs/Desktop/GHC_Build/ghc-6.10.4/libraries/cabal- bin /Users/bjs/Desktop/GHC_Build/install/bin/ghc /Users/bjs/Desktop/ GHC_Build/ghc-6.10.4/libraries/bootstrapping.conf 1.6.0.3 clean -- distpref=dist-bootstrapping cleaning... cd hpc /Users/bjs/Desktop/GHC_Build/ghc-6.10.4/libraries/cabal- bin /Users/bjs/Desktop/GHC_Build/install/bin/ghc /Users/bjs/Desktop/ GHC_Build/ghc-6.10.4/libraries/bootstrapping.conf 1.6.0.3 configure -- distpref=dist-bootstrapping --with-compiler=/Users/bjs/Desktop/ GHC_Build/install/bin/ghc --with-hc-pkg=/Users/bjs/Desktop/GHC_Build/ install/bin/ghc-pkg --package-db=/Users/bjs/Desktop/GHC_Build/ ghc-6.10.4/libraries/bootstrapping.conf.tmp Configuring hpc-0.5.0.3... command-line: warning: __PIC__ redefined built-in: warning: this is the location of the previous definition cd hpc /Users/bjs/Desktop/GHC_Build/ghc-6.10.4/libraries/cabal- bin /Users/bjs/Desktop/GHC_Build/install/bin/ghc /Users/bjs/Desktop/ GHC_Build/ghc-6.10.4/libraries/bootstrapping.conf 1.6.0.3 build -- distpref=dist-bootstrapping Preprocessing library hpc-0.5.0.3... ld: library not found for -lgmp collect2: ld returned 1 exit status linking dist-bootstrapping/build/Trace/Hpc/Reflect_hsc_make.o failed command was: /usr/bin/gcc -L/Users/bjs/Desktop/GHC_Build/install/lib/ ghc-6.8.3/lib/directory-1.0.0.1 -L/Users/bjs/Desktop/GHC_Build/install/ lib/ghc-6.8.3/lib/filepath-1.1.0.0 -L/Users/bjs/Desktop/GHC_Build/ install/lib/ghc-6.8.3/lib/old-time-1.0.0.0 -L/Users/bjs/Desktop/ GHC_Build/install/lib/ghc-6.8.3/lib/old-locale-1.0.0.0 -L/Users/bjs/ Desktop/GHC_Build/install/lib/ghc-6.8.3/lib/containers-0.1.0.2 -L/ Users/bjs/Desktop/GHC_Build/install/lib/ghc-6.8.3/lib/array-0.1.0.0 -L/ Users/bjs/Desktop/GHC_Build/install/lib/ghc-6.8.3/lib/base-3.0.2.0 -L/ Users/bjs/Desktop/GHC_Build/install/lib/ghc-6.8.3 -lm -lgmp -ldl dist- bootstrapping/build/Trace/Hpc/Reflect_hsc_make.o -o dist-bootstrapping/ build/Trace/Hpc/Reflect_hsc_make make[1]: *** [bootstrapping.conf] Error 1 make: *** [stage1] Error 2 [~/Desktop/GHC_Build/ghc-6.10.4] bjs$ As you can see, it doesn't even attempt to tell gcc where to find libgmp. This has the feeling of an RTM question, and if it is then I apologise. I've not seen anything about this in the M, though. Cheers, Barney. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Snow Leopard GHC
Am Freitag 25 September 2009 11:56:54 schrieb Barney Stratford: As you can see, it doesn't even attempt to tell gcc where to find libgmp. This has the feeling of an RTM question, and if it is then I apologise. I've not seen anything about this in the M, though. Cheers, Barney. As a workaround, you might try to set the appropriate enironment variables (check with man gcc which ones are required) to include /sw/include resp. /sw/lib ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Snow Leopard GHC
As a workaround, you might try to set the appropriate enironment variables Setting LIBRARY_PATH seems to help, but there must be a better way! Thanks. Barney. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Snow Leopard GHC
Latest update on getting GHC working 64-bit on Snow Leopard. I've been building 6.8.3, simply because it was the version I had running before so might give fewer problems. To get the compiler working, apply this patch (which I borrowed from the Darcs repository): diff -uit a/compiler/cmm/CLabel.hs b/compiler/cmm/CLabel.hs --- a/compiler/cmm/CLabel.hs +++ b/compiler/cmm/CLabel.hs @@ -816,6 +816,10 @@ pprDynamicLinkerAsmLabel :: DynamicLinkerLabelInfo - CLabel - SDoc #if x86_64_TARGET_ARCH darwin_TARGET_OS +pprDynamicLinkerAsmLabel CodeStub lbl + = char 'L' pprCLabel lbl text $stub +pprDynamicLinkerAsmLabel SymbolPtr lbl + = char 'L' pprCLabel lbl text $non_lazy_ptr pprDynamicLinkerAsmLabel GotSymbolPtr lbl = pprCLabel lbl text @GOTPCREL pprDynamicLinkerAsmLabel GotSymbolOffset lbl Make sure you have a working 32-bit GHC as well as libraries (libgmp, etc).for both 32 and 64-bit architectures. Then say ./configure --build=x86_64-apple-darwin --host=x86_64-apple-darwin -- target=x86_64-apple-darwin make It will compile an x86_64 GHC for you, happily unaware that the GHC you're using for the build is a 32-bit one. The stage1 compiler is, of course, a 32-bit binary that produces 64-bit binaries. I found that the resulting compiler can build itself (stage3) and can say Hello World, so it looks like it works correctly. I've still not got GHCi working, though. I've managed to narrow down the source of the trouble with the linker in GHCi, and it looks like there are some bugs as well as missing parts, which is why it kept launching itself to the moon. Still working on that one: patch to follow. For now, you can at least compile your code and run it non-interactively. Barney. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Snow Leopard GHC
On 24/09/2009 09:55, Barney Stratford wrote: Latest update on getting GHC working 64-bit on Snow Leopard. I've been building 6.8.3, simply because it was the version I had running before so might give fewer problems. To get the compiler working, apply this patch (which I borrowed from the Darcs repository): diff -uit a/compiler/cmm/CLabel.hs b/compiler/cmm/CLabel.hs --- a/compiler/cmm/CLabel.hs +++ b/compiler/cmm/CLabel.hs @@ -816,6 +816,10 @@ pprDynamicLinkerAsmLabel :: DynamicLinkerLabelInfo - CLabel - SDoc #if x86_64_TARGET_ARCH darwin_TARGET_OS +pprDynamicLinkerAsmLabel CodeStub lbl + = char 'L' pprCLabel lbl text $stub +pprDynamicLinkerAsmLabel SymbolPtr lbl + = char 'L' pprCLabel lbl text $non_lazy_ptr pprDynamicLinkerAsmLabel GotSymbolPtr lbl = pprCLabel lbl text @GOTPCREL pprDynamicLinkerAsmLabel GotSymbolOffset lbl Make sure you have a working 32-bit GHC as well as libraries (libgmp, etc).for both 32 and 64-bit architectures. Then say ./configure --build=x86_64-apple-darwin --host=x86_64-apple-darwin --target=x86_64-apple-darwin make It will compile an x86_64 GHC for you, happily unaware that the GHC you're using for the build is a 32-bit one. The stage1 compiler is, of course, a 32-bit binary that produces 64-bit binaries. I found that the resulting compiler can build itself (stage3) and can say Hello World, so it looks like it works correctly. I've still not got GHCi working, though. I've managed to narrow down the source of the trouble with the linker in GHCi, and it looks like there are some bugs as well as missing parts, which is why it kept launching itself to the moon. Still working on that one: patch to follow. For now, you can at least compile your code and run it non-interactively. Nice going - sounds like you've got the furthest so far. Others have been going via an unregisterised build, which seems to be more problematic (though it shouldn't be). It should be possible to use your 6.8.3 to bootstrap your way to 6.12.1, have you tried that? I doubt it will fix your GHCi problems, though. But it should be possible to then make a distribution for others to try. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Snow Leopard GHC
Only limited success with GHCi, I'm afraid. The problem seems to be that Snow Leopard is much stricter about security than Leopard was. (Caveat - I don't really know what I'm talking about.) In particular, I don't think it will let you execute code outside of the __TEXT segment, which is exactly what GHCi tries to do - hence the bus errors. I've tried just letting the dynamic linker (dyld) sort everything out for us, but this failed because not all symbols are dynamically linked, and the statically linked ones are invisible to it. One change that will be necessary in any case: towards the end of rts/ Linker.c, change case X86_64_RELOC_SIGNED: ASSERT(reloc-r_pcrel); thing += value - baseValue; break; to case X86_64_RELOC_SIGNED: case X86_64_RELOC_SIGNED_1: case X86_64_RELOC_SIGNED_2: case X86_64_RELOC_SIGNED_4: ASSERT(reloc-r_pcrel); thing += value - baseValue; break; I won't be able to hack on this any more for a few days, as I'm off to the mountains. Maybe someone else can try. Barney. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Snow Leopard GHC
I've been trying to get GHC working for x86_64 on Snow Leopard, with a certain amount of success, but have got stuck. Maybe one of you could point me in the right direction. I now have a working compiler, but the linker in the runtime system seems to be missing some stuff. Specifically, in rts/Linker.c, there are references to X86_64_RELOC_UNSIGNED, X86_64_RELOC_SIGNED and so on, but it simply barfs when faced with a X86_64_RELOC_SIGNED_1 etc. I'd thought it would be a matter of adding a few lines of code, but everything I've tried has ended in tears. Trouble is, none of the documentation mentions X86_64_RELOC_SIGNED_1, although it does appear in C headers. It occurs only rarely in source examples, and it really isn't clear to me how I should proceed. Any ideas? Cheers, Barney. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
