Re: ghc 6.6 for mac os x (intel)
I installed the darwin ports readline and created the following soft link: /usr/local/lib/libreadline.5.1.dylib - /opt/local/lib/libreadline. 5.1.dylib Alternatively, you could install the darwin ports readline and set the DYLD_LIBRARY_PATH variable. I prefer not to use DYLD_LIBRARY_PATH. -reilly On Feb 6, 2007, at 7:15 AM, Ariel Apostoli wrote: but when I try installing ghc from that page it seems to install fine but when I invoke /usr/local/bin/ghc i get: dyld: Library not loaded: /opt/local/lib/libreadline.5.1.dylib Referenced from: /usr/local/lib/ghc-6.6/ghc-6.6 Reason: image not found Trace/BPT trap My version of mac os x is 10.4.8 Again thanks for your time and help so far! Ariel Kirsten Chevalier wrote: [redirecting to the list] On 2/5/07, Ariel Apostoli [EMAIL PROTECTED] wrote: Hello Kirsten, Thanks so much for your time and help so far. However, I am still stuck on the issue when I try to do this: ./configure --with-readline-includes=/usr/local \ --with-readline-libraries=/usr/local I get: checking build system type... i686-apple-darwin8.8.1 checking host system type... i686-apple-darwin8.8.1 checking target system type... i686-apple-darwin8.8.1 Canonicalised to: i386-apple-darwin checking for path to top of build tree... /Users/ariel/work/ghc/ ghc-6.6 checking for ghc... no checking for ghc-pkg matching ... no checking for ghc-pkg... no checking whether ghc has readline package... no checking for nhc... no checking for nhc98... no checking for hbc... no configure: error: GHC is required unless bootstrapping from .hc files. Do you know what should I do to avoid this? Do you already have a binary version of GHC installed? If you want to build GHC from source, you need a binary of GHC installed already, like the error message suggests. (Unless you want to bootstrap from .hc files, but I've never done that, so I don't know.) See: http://haskell.org/ghc/download_ghc_66.html#macosxintel You didn't say what version of Mac OS X you were using; if it's anything older than 10.3, you're probably SOL. Cheers, Kirsten ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Replacement for GMP: Update
personal target and perhaps it is for the benefit of the next GHC release on 26 August: it may take a long time to work with OpenSSL to modify their library. It might be worth looking into, just to cover all bases. The problem for me is that I seem to be doing all the work, albeit rather slowly; I simply do not have the time to follow every possibility. (And way further back: Have we tried to discuss the LGPL licence of GMP withthe authors? I am not really into all these matters, sorry if this doesn'tmake sense.) That is actually a good idea; it has been suggested before for an individual developer. I doubt very much the Free Software Foundation would want to give an exception for one of their flagship products but I admit, that kind of thinking is, well, cowardly. As for whether I am the person to ask them, I could float the question but I could not represent the GHC Team. Failing that, I would suggest considering the development of the modifiedlibrary to a form that would allow independent use, apart from its use inGHC. This would add valuable possibilities to your options when choosing theprecise mixture of Haskell and, perhaps, raw C code that best balances yourperformance desires and needs for convenience. Before I actually bind any library with GHC, I will thoroughly test it as a stand-alone library and I will develop some good benchmarks for it as an FFI-based library (using ForeignPtr). The Creators of the GHC, however, have given good arguments why it is Very Good to use GHC's runtime system Garbage Collector to handle the Integer-memory for bignum libraries: it is almost certainly faster, it allows the runtime system's Scheduler to operate on Integers without resorting to the creation or management of Operating System (OS) threads and in general the evaluation of Integers is more a "native" than a "foreign" operation in Haskell programs.I hope I have answered a few of your points; some of them have given me more work but that is all right, I guess. You did say that you frequently use Integers in Haskell. If you have the time, would you be able to find any programs you might have that displayed poor Integer performance or possibly bottlenecks in the current system? It might be helpful for benchmarking the replacement--this is really supposed to be an "upgrade," after all.Best regards,Peter___Glasgow-haskell-users mailing listGlasgow-haskell-users@haskell.orghttp://www.haskell.org/mailman/listinfo/glasgow-haskell-users Reilly Hayes[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: HEAD: Problem Linking genapply in 6.5.20060510
thanks, As this occurred while bootstrapping from .hc files, there are no .hi files built yet. -reilly hayes On May 12, 2006, at 7:57 PM, Esa Ilari Vuokko wrote: On 5/13/06, Reilly Hayes [EMAIL PROTECTED] wrote: Hi I suspect today's problem is pretty easy to figure out for a GHC expert, but I'm not. When I try to build utils/genapply, the link fails because the symbols _GHCziList_lvl22_closure and _GHCziList_zdwlen_info are undefined. I'll include the build log On actual problem, I have no idea except the simple..maybe .hi files were inconsistent with object files. below. While we're on the topic, can somebody explain the algorithm used to generate these symbol names? I might be wrong on any of this, but I'm giving it a shot as it might take over weekend before Simons or anyone else answers. It's called zencoding, found in http://darcs.haskell.org/ghc/compiler/utils/Encoding.hs _ on start is just some typical c-name thingy. Otherwise those symbols are from GHC.List module. _info and _closure mean different use of that name that comes before them (lvl22 and $wlen). I think compiler/cmm/CLabel.hs might help on that, or rather modules that use it. I am not sure how to track name generators for lvl22 and $. HTH, --Esa Reilly Hayes ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Failure building HEAD in libraries/base/Data/ByteString.hs
As of 6.5.20050610 this still occurs on both the intel mac and intel
linux (Gcc 4.0.1 gcc 4.0.2 respectively). Setting -fno-inline for
gcc has no effect.
-reilly hayes
On May 9, 2006, at 1:20 AM, Simon Marlow wrote:
Often I find these are the result of gcc inlining something, or
using its built-in primitives. We already pass -fno-builtin to gcc
on x86. Don - are there any C functions being inlined in
ByteString? If so, it might be a good idea to turn off the inlining.
Cheers,
Simon
Donald Bruce Stewart wrote:
There's been a few changes since then, perhaps try again with last
night's snapshot?
dons:
Hmm! Very interesting. Register spill classes, eh? SimonM?
-- Don
rfh:
I get the following error when trying to bootstrap the
6.5.20060506 snapshot from hc files (registerised):
gcc -x c Data/ByteString.hc -o Data/ByteString.raw_s -S -O
-fno-defer-pop -fomi
t-frame-pointer -mdynamic-no-pic
-DDONT_WANT_WIN32_DLL_SUPPORT -mdynamic-no-pi
c -D__GLASGOW_HASKELL__=605 -O -mdynamic-no-pic
-I/Users/rfh/haskell/mac/ghc-6.
5.20060506/includes
-I/Users/rfh/haskell/mac/ghc-6.5.20060506/libraries/base/inc
lude
-I/Users/rfh/haskell/mac/ghc-6.5.20060506/libraries/unix/inc
lude -I/Users/r
fh/haskell/mac/ghc-6.5.20060506/libraries/parsec/include
-I. `echo | sed '
s/^$/-DSTOLEN_X86_REGS=4/'`
Data/ByteString.hc: In function
'DataziByteString_zdwccall_entry':
Data/ByteString.hc:8631: error: unable to find a register to
spill in class 'DIR
EG'
Data/ByteString.hc:8631: error: this is the insn:
(insn 22 45 23 0 (parallel [
(set (reg:SI 2 cx [64])
(unspec:SI [
(mem:BLK (reg:SI 1 dx [orig:66 _cdHE
] [66]) [0 A8])
(reg:QI 0 ax [68])
(const_int 1 [0x1])
(reg:SI 2 cx [67])
] 20))
(use (reg:SI 19 dirflag))
(clobber (reg:SI 1 dx [orig:66 _cdHE ] [66]))
(clobber (reg:CC 17 flags))
]) 479 {*strlenqi_1} (insn_list:REG_DEP_TRUE 18
(insn_list:REG_DEP_TRUE
19 (insn_list:REG_DEP_TRUE 20 (insn_list:REG_DEP_TRUE 21
(nil)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_UNUSED (reg:SI 1 dx [orig:66 _cdHE ]
[66])
(expr_list:REG_DEAD (reg:SI 19 dirflag)
(expr_list:REG_DEAD (reg:SI 2 cx [67])
(expr_list:REG_DEAD (reg:QI 0 ax [68])
(expr_list:REG_DEAD (reg:SI 1 dx
[orig:66 _cdHE ] [66])
(expr_list:REG_UNUSED (reg:CC 17
flags)
(expr_list:REG_UNUSED
(reg:SI 1 dx [orig:66 _cdH
E ] [66])
(nil))
Data/ByteString.hc:8631: confused by earlier errors, bailing
out
make[1]: *** [Data/ByteString.raw_s] Error 1
make: *** [all] Error 1
I am insufficiently experienced with the build process to
know if this was from an error in creating the .hc file or a
problem with the source. I have noticed that the file
ByteString.hs seems to be new.
I am building the .hc files on 386 linux (Ubuntu breezy
badger):
linux kernel 2.6.12
ghc-6.5.20060502 is installed
gcc is 4.0.2
I am using the registerised .hc files to bootstrap to Max OS
X x86
Mac OS X 10.4.6
no ghc installed
gcc is 4.0.1 (as included in Xcode)
Reilly Hayes
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reilly Hayes
[EMAIL PROTECTED]
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Failure building HEAD in libraries/base/Data/ByteString.hs
Gentlemen,
ghc -v was not required, as I am building this using .hc files from
another host. Adding -fno-builtin to the CC opts did resolve the
problem. Furthermore, I believe I have confirmed that strlen is the
problem by succesfully compiling the library using -fno-builtin-
strlen instead of -fno-builtin.
Thank you,
reilly hayes
On May 12, 2006, at 2:20 AM, Simon Marlow wrote:
I'm pretty sure this is to do with calls to strlen() from
Data.ByteString.
Can you check for sure that gcc is being passed -fno-builtin? (use
ghc -v).
Failing that, we might have to use a private version of strlen()
that gcc doesn't try to inline.
Cheers,
Simon
Reilly Hayes wrote:
As of 6.5.20050610 this still occurs on both the intel mac and
intel linux (Gcc 4.0.1 gcc 4.0.2 respectively). Setting -fno-
inline for gcc has no effect.
-reilly hayes
On May 9, 2006, at 1:20 AM, Simon Marlow wrote:
Often I find these are the result of gcc inlining something, or
using its built-in primitives. We already pass -fno-builtin to
gcc on x86. Don - are there any C functions being inlined in
ByteString? If so, it might be a good idea to turn off the
inlining.
Cheers,
Simon
Donald Bruce Stewart wrote:
There's been a few changes since then, perhaps try again with last
night's snapshot?
dons:
Hmm! Very interesting. Register spill classes, eh? SimonM?
-- Don
rfh:
I get the following error when trying to bootstrap the
6.5.20060506 snapshot from hc files (registerised):
gcc -x c Data/ByteString.hc -o Data/ByteString.raw_s -S -O
-fno-defer-pop -fomi
t-frame-pointer -mdynamic-no-pic
-DDONT_WANT_WIN32_DLL_SUPPORT -mdynamic-no-pi
c -D__GLASGOW_HASKELL__=605 -O -mdynamic-no-pic
-I/Users/rfh/haskell/mac/ghc-6.
5.20060506/includes
-I/Users/rfh/haskell/mac/ghc-6.5.20060506/libraries/base/inc
lude
-I/Users/rfh/haskell/mac/ghc-6.5.20060506/libraries/unix/inc
lude -I/Users/r
fh/haskell/mac/ghc-6.5.20060506/libraries/parsec/include
-I. `echo | sed '
s/^$/-DSTOLEN_X86_REGS=4/'`
Data/ByteString.hc: In function
'DataziByteString_zdwccall_entry':
Data/ByteString.hc:8631: error: unable to find a register to
spill in class 'DIR
EG'
Data/ByteString.hc:8631: error: this is the insn:
(insn 22 45 23 0 (parallel [
(set (reg:SI 2 cx [64])
(unspec:SI [
(mem:BLK (reg:SI 1 dx [orig:66 _cdHE
] [66]) [0 A8])
(reg:QI 0 ax [68])
(const_int 1 [0x1])
(reg:SI 2 cx [67])
] 20))
(use (reg:SI 19 dirflag))
(clobber (reg:SI 1 dx [orig:66 _cdHE ] [66]))
(clobber (reg:CC 17 flags))
]) 479 {*strlenqi_1} (insn_list:REG_DEP_TRUE 18
(insn_list:REG_DEP_TRUE
19 (insn_list:REG_DEP_TRUE 20 (insn_list:REG_DEP_TRUE 21
(nil)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_UNUSED (reg:SI 1 dx [orig:66 _cdHE ]
[66])
(expr_list:REG_DEAD (reg:SI 19 dirflag)
(expr_list:REG_DEAD (reg:SI 2 cx [67])
(expr_list:REG_DEAD (reg:QI 0 ax [68])
(expr_list:REG_DEAD (reg:SI 1 dx
[orig:66 _cdHE ] [66])
(expr_list:REG_UNUSED (reg:CC 17
flags)
(expr_list:REG_UNUSED
(reg:SI 1 dx [orig:66 _cdH
E ] [66])
(nil))
Data/ByteString.hc:8631: confused by earlier errors, bailing
out
make[1]: *** [Data/ByteString.raw_s] Error 1
make: *** [all] Error 1
I am insufficiently experienced with the build process to
know if this was from an error in creating the .hc file or a
problem with the source. I have noticed that the file
ByteString.hs seems to be new.
I am building the .hc files on 386 linux (Ubuntu breezy
badger):
linux kernel 2.6.12
ghc-6.5.20060502 is installed
gcc is 4.0.2
I am using the registerised .hc files to bootstrap to Max OS
X x86
Mac OS X 10.4.6
no ghc installed
gcc is 4.0.1 (as included in Xcode)
Reilly Hayes
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reilly Hayes
[EMAIL PROTECTED]
Reilly Hayes
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
HEAD: Problem Linking genapply in 6.5.20060510
I'm continuing in my quest to produce a clean build of GHC for Mac intel. I'm using registerised .hc files built on 386 linux. I suspect today's problem is pretty easy to figure out for a GHC expert, but I'm not. When I try to build utils/genapply, the link fails because the symbols _GHCziList_lvl22_closure and _GHCziList_zdwlen_info are undefined. I'll include the build log below. While we're on the topic, can somebody explain the algorithm used to generate these symbol names? The build log was: gcc -x c GenApply.hc -o GenApply.raw_s -S -O -fno-builtin -fno-defer- pop -fomit-frame-pointer -mdynamic-no-pic - DDONT_WANT_WIN32_DLL_SUPPORT -mdynamic-no-pic - D__GLASGOW_HASKELL__=605 -O -I/Users/rfh/ghc-6.5/mac/ ghc-6.5.20060510/includes -I/Users/rfh/ghc-6.5/mac/ghc-6.5.20060510/ libraries/base/include -I/Users/rfh/ghc-6.5/mac/ghc-6.5.20060510/ libraries/unix/include -I/Users/rfh/ghc-6.5/mac/ghc-6.5.20060510/ libraries/parsec/include -I/Users/rfh/ghc-6.5/mac/ghc-6.5.20060510/ libraries/readline/include-I. `echo | sed 's/^$/- DSTOLEN_X86_REGS=4/'` ../../driver/mangler/ghc-asm GenApply.raw_s GenApply.s as-o GenApply.o GenApply.s gcc -o genapply -fno-builtin -fno-defer-pop -fomit-frame-pointer - mdynamic-no-pic -DDONT_WANT_WIN32_DLL_SUPPORT -mdynamic-no-pic - D__GLASGOW_HASKELL__=605 -O -I/Users/rfh/ghc-6.5/mac/ ghc-6.5.20060510/includes -I/Users/rfh/ghc-6.5/mac/ghc-6.5.20060510/ libraries/base/include -I/Users/rfh/ghc-6.5/mac/ghc-6.5.20060510/ libraries/unix/include -I/Users/rfh/ghc-6.5/mac/ghc-6.5.20060510/ libraries/parsec/include -I/Users/rfh/ghc-6.5/mac/ghc-6.5.20060510/ libraries/readline/include-L/Users/rfh/ghc-6.5/mac/ ghc-6.5.20060510/rts -L/Users/rfh/ghc-6.5/mac/ghc-6.5.20060510/rts/ gmp -L/Users/rfh/ghc-6.5/mac/ghc-6.5.20060510/libraries/base -L/Users/ rfh/ghc-6.5/mac/ghc-6.5.20060510/libraries/base/cbits -L/Users/rfh/ ghc-6.5/mac/ghc-6.5.20060510/libraries/haskell98 -L/Users/rfh/ghc-6.5/ mac/ghc-6.5.20060510/libraries/parsec -L/Users/rfh/ghc-6.5/mac/ ghc-6.5.20060510/libraries/Cabal -L/Users/rfh/ghc-6.5/mac/ ghc-6.5.20060510/libraries/template-haskell -L/Users/rfh/ghc-6.5/mac/ ghc-6.5.20060510/libraries/readline -L/Users/rfh/ghc-6.5/mac/ ghc-6.5.20060510/libraries/unix -L/Users/rfh/ghc-6.5/mac/ ghc-6.5.20060510/libraries/unix/cbits -u _GHCziBase_Izh_static_info -u _GHCziBase_Czh_static_info -u _GHCziFloat_Fzh_static_info -u _GHCziFloat_Dzh_static_info -u _GHCziPtr_Ptr_static_info -u _GHCziWord_Wzh_static_info -u _GHCziInt_I8zh_static_info -u _GHCziInt_I16zh_static_info -u _GHCziInt_I32zh_static_info -u _GHCziInt_I64zh_static_info -u _GHCziWord_W8zh_static_info -u _GHCziWord_W16zh_static_info -u _GHCziWord_W32zh_static_info -u _GHCziWord_W64zh_static_info -u _GHCziStable_StablePtr_static_info -u _GHCziBase_Izh_con_info -u _GHCziBase_Czh_con_info -u _GHCziFloat_Fzh_con_info -u _GHCziFloat_Dzh_con_info -u _GHCziPtr_Ptr_con_info -u _GHCziStable_StablePtr_con_info -u _GHCziBase_False_closure -u _GHCziBase_True_closure -u _GHCziPack_unpackCString_closure -u _GHCziIOBase_stackOverflow_closure -u _GHCziIOBase_heapOverflow_closure -u _GHCziIOBase_NonTermination_closure -u _GHCziIOBase_BlockedOnDeadMVar_closure -u _GHCziIOBase_Deadlock_closure -u _GHCziWeak_runFinalizzerBatch_closure -u ___stginit_Prelude GenApply.o -lHSreadline -lHStemplate-haskell -lHSunix - lHSunix_cbits -lHSCabal -lHShaskell98 -lHSbase -lHSbase_cbits - lHSparsec -lHSrts -lgmp -lm -lreadline -lncurses -ldl /usr/bin/ld: Undefined symbols: _GHCziList_lvl22_closure _GHCziList_zdwlen_info collect2: ld returned 1 exit status make[1]: *** [genapply] Error 1 Reilly Hayes ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problems building HEAD
Simon, Thanks for all your help. I've tried file individual messages when I'm pretty sure I've identified a problem with the distribution itself. However, I thought it might be useful to post more on my experiences in creating this build. 1) REGISTERISED HC FILE CREATION (on Linux x86) The way I built the registerised .hc files in the original e-mail missed several. However, doing a vanilla make with the following mk/ build.mk file will generate them: -- SRC_HC_OPTS = -H32m -O -fasm -Rghc-timing -keep-hc-files GhcStage1HcOpts = -O0 -DDEBUG GhcLibHcOpts= -O GhcLibWays = SplitObjs = NO make hc-file-bundle Project=ghc creates the tar file with the hc files. 2) REGISTERISED HC FILE BOOT (on Mac OS X 10.4.6 x86) On May 2, 2006, at 4:51 AM, Simon Marlow wrote: I'm guessing the sequence should be something like this: ./configure --enable-hc-boot $MAKE -C utils/mkdependC boot all $MAKE -C includes boot all $MAKE -C rts boot all $MAKE -C libraries boot all GhcBootLibs=YES $MAKE -C compat boot all $MAKE -C utils boot all $MAKE -C compiler boot all Try that, and let me know how far you get. Cheers, Simon I've managed to build a stage1 compiler that executes, but I'm not sure it works. I tried a hello world test program as suggested in the documentation. It fails to compile because it can't find the .hi files for the prelude. But, if I understand correctly, I won't have .hi files until I've rebuilt the libraries with the stage1 compiler. Is this right? 3) Refinements to your directions The following need to be made prior to building RTS $MAKE -C utils/unlit boot all $MAKE -C utils/mkdirhier boot all $MAKE -C driver/mangler The RTS build generates endless warnings about .o files having no symbols and functions not having previous prototypes. I googled for both and is seems that it is OK, but I would like confirmation. utils/genprimopcode is problematic. The libraries build fails without it, but it wants the libraries to be built in order to link. SOMEHOW (I think by typing 'make' at the top level) I ended up with a viable executable for this. Unfortunately, I can't recreate it from scratch. Now that I have it, I admit that I've taken to using it to salt new builds rather than figure out what is going on. The following readline and ncurses are problematic on the Mac and should be replaced with verisons from gnu. Thanks to whoever posted bug #766, I used the following procedure prior to running configure. o Download ncurses and readline and install them into /usr/local/ lib. Be sure to build ncurses as shared. o set export LD_FLAGS=-L/usr/local/lib and CPP_FLAGS=-I/usr/ local/include o make sure these are in your environment when you configure and do your build. cheers, Reilly Hayes ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC 6.6 and Ticket #608
Any chance of getting ticket #608 onto the list for the 6.6 release? Ticket #608 is "Make the NCG able to compile the RTS". Please correct me if I am wrong, but my understanding of the dependencies suggests that this is the key obstacle to dynamically linked builds on x86 platforms. My reasoning is that GCC generated position independent code conflicts with the Mangler and that the RTS is the only code that must be built with the Mangler. Reilly Hayes ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Failure building HEAD in libraries/base/Data/ByteString.hs
I get the following error when trying to bootstrap the 6.5.20060506 snapshot from hc files (registerised):gcc -x c Data/ByteString.hc -o Data/ByteString.raw_s -S -O -fno-defer-pop -fomit-frame-pointer -mdynamic-no-pic -DDONT_WANT_WIN32_DLL_SUPPORT -mdynamic-no-pic -D__GLASGOW_HASKELL__=605 -O -mdynamic-no-pic -I/Users/rfh/haskell/mac/ghc-6.5.20060506/includes -I/Users/rfh/haskell/mac/ghc-6.5.20060506/libraries/base/include -I/Users/rfh/haskell/mac/ghc-6.5.20060506/libraries/unix/include -I/Users/rfh/haskell/mac/ghc-6.5.20060506/libraries/parsec/include -I. `echo | sed 's/^$/-DSTOLEN_X86_REGS=4/'`Data/ByteString.hc: In function 'DataziByteString_zdwccall_entry':Data/ByteString.hc:8631: error: unable to find a register to spill in class 'DIREG'Data/ByteString.hc:8631: error: this is the insn:(insn 22 45 23 0 (parallel [ (set (reg:SI 2 cx [64]) (unspec:SI [ (mem:BLK (reg:SI 1 dx [orig:66 _cdHE ] [66]) [0 A8]) (reg:QI 0 ax [68]) (const_int 1 [0x1]) (reg:SI 2 cx [67]) ] 20)) (use (reg:SI 19 dirflag)) (clobber (reg:SI 1 dx [orig:66 _cdHE ] [66])) (clobber (reg:CC 17 flags)) ]) 479 {*strlenqi_1} (insn_list:REG_DEP_TRUE 18 (insn_list:REG_DEP_TRUE 19 (insn_list:REG_DEP_TRUE 20 (insn_list:REG_DEP_TRUE 21 (nil) (expr_list:REG_UNUSED (reg:CC 17 flags) (expr_list:REG_UNUSED (reg:SI 1 dx [orig:66 _cdHE ] [66]) (expr_list:REG_DEAD (reg:SI 19 dirflag) (expr_list:REG_DEAD (reg:SI 2 cx [67]) (expr_list:REG_DEAD (reg:QI 0 ax [68]) (expr_list:REG_DEAD (reg:SI 1 dx [orig:66 _cdHE ] [66]) (expr_list:REG_UNUSED (reg:CC 17 flags) (expr_list:REG_UNUSED (reg:SI 1 dx [orig:66 _cdHE ] [66]) (nil))Data/ByteString.hc:8631: confused by earlier errors, bailing outmake[1]: *** [Data/ByteString.raw_s] Error 1make: *** [all] Error 1I am insufficiently experienced with the build process to know if this was from an error in creating the .hc file or a problem with the source. I have noticed that the file ByteString.hs seems to be new.I am building the .hc files on 386 linux (Ubuntu breezy badger): linux kernel 2.6.12 ghc-6.5.20060502 is installed gcc is 4.0.2I am using the registerised .hc files to bootstrap to Max OS X x86 Mac OS X 10.4.6 no ghc installed gcc is 4.0.1 (as included in Xcode) Reilly Hayes ___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Conflict in HEAD between suffix.mk and config.mk.in
config.mk.in defines MANGLER while suffix.mk uses GHC_MANGLER. I have changed suffix.mk in my build directory to use MANGLER, but GHC_MANGLER is more consistent with the variables used to construct MANGLER (GHC_MANGLER_DIR GHC_MANGLER_PGM) Reilly Hayes [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Porting GHC to OSX86?
You'll get a better response to this on the glasgow-haskell-users list. I'm cross-posting my reply. I'm brand new to hacking on GHC, but I've been working on this in my pitifully meagre spare time. The actual expert is Wolfgang Thaller, but he doesn't seem to be around the lists lately. I was able to generate hc files on a 386 linux box (actually on a Parallels virtual machine on my mac, as my linux boxen all run 64 bit linuces).I'll share my findings so far: 1) STABLE does not have the appropriate code in the Mangler to deal with Darwin/86. I've been playing with various versions of HEAD. 2) HEAD has gone through a major revision to the directory structure. The documentation and some of the build processes have not caught up. Simon Marlow sent a helpful e-mail to the ghc users list a few days ago that you should look at. 3) Building the .hc files mostly requires the appropriate settings in mk/build.mk on the Host (linux) machine. I'll include my build.mk below. There is a target in the top level makefile called hc-file- bundle (which needs to be invoked with the parameter ProjectNameShort=ghc in HEAD and Project=ghc in STABLE). This target packages up the .hc files, but does not build them. Some of the .hc files in utils (genapply, genprimopcode, ghc-pkg) don't get built. I just cd to the directories and make them by hand (be sure to use the in-place compiler). A GhcUtilsHcOpts variable in the make structure would be nice (in order to pass -keep-hc-files to ghc when building these on the host). 4) I have been working with Registerised hc files. This may have been a mistake, as registerised code seems to present some unique challenges on Darwin/86. See the items below for a discussion. 5) If I understand correctly (somebody with better knowledge please correct me), there is a register allocation conflict between ghc and relocatable code generated by gcc on the 386 (gcc flag -fPIC). This limits ghc to producing static binaries. The gcc in Xcode builds relocatable code by default and requires -static to build static binaries. I think this conflict is limited to code that goes through the Mangler (registerized code). 6) If I understand correctly, there is code in the RTS that cannot be built using the native code generator. Which suggests that we're stuck with static binaries. There is a ticket to fix this in HEAD. 7) Mac OS X really doesn't like static binaries. In fact, in order to link a static binary, you have to go to opendarwin and download the Csu package to build crt0.o. It's not included in any of the development tools. Apple warns that static binaries are likely to fail to operate in O/S version changes. Curently I'm fighting with the Makefiles to figure out how to get the -static flag stuffed into all of the invocations of gcc. Some of the invocations in rts components don't seem to obey the normal variables used in the makefile structure. I haven't had time to puzzle this out and won't for a few days. mk/build.mk used to generate hc files: GhcLibHcOpts = -O -fasm -keep-hc-files GhcRtsHcOpts = -fasm -keep-hc-files GhcWithInterpreter = NO GhcStage1HcOpts = -O GhcStage2HcOpts = -O -fasm -keep-hc-files SRC_HC_OPTS += -H32m -reilly hayes On May 5, 2006, at 7:34 PM, Scott Weeks wrote: Hi All, Does anyone know if there's been any headway on this? If there's not a port available, where do I go about finding the hc files? Could I compile on a windows or linux x86 box and use the generated hc files to bootstrap? Cheers, Scott On 22/03/2006, at 7:09 AM, Deling Ren wrote: Hi there, Has anyone made any attempt to port GHC to Mac OS X on x86? Wolfgang Thaller’s binary package runs over Rosetta but slow (not surprising). It can not be used to compile a native version either (I got some errors related to machine registers). I tried to do a bootstrap but can't find the .HC files mentioned in the manual. They don't seem to be on the download page of GHC. Any ideas? Thanks. Deling___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Reilly Hayes [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Problems building HEAD
I'm trying to build head (latest try with ghc-6.5.20060429) for my macbook pro (Mac OS X intel) using hc files built on a x86 linux (Ubuntu Breezy Badger). I have the following issues:1) Issues with bookstrap.mkbootstrap.mk in head contains the following lines TOP_SAVED := $(TOP) TOP:=$(TOP)/ghc include $(TOP)/mk/version.mk include $(TOP)/mk/paths.mk # Reset TOP TOP:=$(TOP_SAVED)However, those files are not at those locations. Looking back at 6.4.2, it seems that they were in those locations in 6.4.2, but that changes in the directory structure mean that the line that sets top to $(TOP)/ghc is obsolete. version.mk is nowhere to be seen, nor is version.mk.in. It looks as if the variables set in this file are now set in config.mk and that version.mk is no longer required. If that's true, I can replace all of the lines above with: include $(TOP)/mk/paths.mk2) Building the .hc filesThe building guide says that I can build hc files on another host running on the same platform. The word platform seems to be used to describe architecture in some places and architecture O/S in others. I have assumed that it means architecture in this case (if we already have a compiler that runs on the same Arch OS, why are we porting).What the building guide does not do is provide instructions for producing registerized hc files. The recipe I have stumbled onto is this a) Create mk/build.mk and add the following lines: GhcLibHcOpts = -O -fvia-C -keep-hc-files GhcRtsHcOpts = -keep-hc-files GhcStage1HcOpts = -O -fvia-C -keep-hc-files GhcStage2HcOpts = -O -fvia-C -keep-hc-files b) run "./configure" c) run "make" d) I want to run "make hc-file-bundle Project=ghc", but it complains about a few missing files. So first I cd to rts and run "make AutoApply.hc AutoApply_p.hc AutoApply_thr.hc \ AutoApply_thr_p.hc AutoApply_debug.hc AutoApply_thr_debug.hc" e) run "make hc-file-bundle Project=ghc", which works just fine. f) untar the resulting file in the parent directory of ghc-6.5.20060429 on the target machine3) running the build. I'm following the steps in distrib/hc-build by hand, which work out to: ./configure --enable-hc-boot make -C utils boot all make -C ghc boot make -C libraries boot all GhcBootLibs=YES make -C ghc allIs this all correct? I'm having problems with the build in utils, but by then I've already made enough assumptions about how to fix the build that there's little point in asking the question until I've verified that I haven't messed things up upstream.Reilly Hayes ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
