Changes between Initial Version and Version 1 of Ticket #3472


Ignore:
Timestamp:
Sep 8, 2009 2:22:42 PM (5 years ago)
Author:
simonmar
Comment:

regarding the NO_REGS/MINI_INTERPRETER problem, I think I know what went wrong there. We still have some old cruft in the build system that confused me when I made a change to the conditional surrounding the SRC_CC_OPTS setting in ghc.mk. I'll commit a fix.

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #3472

    • Property Difficulty changed from to Unknown
    • Property Component changed from Compiler to Build System
    • Property Milestone changed from to 6.12 branch
  • Ticket #3472 – Description

    initial v1  
    1 I've been trying repeatedly over the past week or two to get an x86_64 build of GHC for OS X, by going through the procedure described at http://hackage.haskell.org/trac/ghc/wiki/Building/Porting.  
     1I've been trying repeatedly over the past week or two to get an x86_64 build of GHC for OS X, by going through the procedure described at [http://hackage.haskell.org/trac/ghc/wiki/Building/Porting].  
    22 
    33I've encountered several problems, and the process is huge and daunting so it's hard to say exactly what's a real error and what causes the breakage, but I'll try to describe what I've seen so far. 
     
    88 
    99This goes smoothly for a while, and then I encounter an error: 
    10  
     10{{{ 
    1111make[1]: *** No rule to make target `rts/dist/build/Apply.o', needed by `rts/dist/build/libHSrts.a'.  Stop. 
    12  
     12}}} 
    1313I check the rts directory and indeed there is an Apply.hc file in there. So I guess the build system forgot that .hc files produce .o files in the case of the rts. Maybe it's missing a .hc.o rule or something, so I tried to figure out the build system files but wasn't able to convince it to build the .hc files. I then emulated the gcc parameters used for other rts .c and .s files and compiled all the .hc files in the RTS myself. So I resume the make and it seems satisfied until it tries to build the rts in a different way (v, instead of l). Again, I compile all the .hc files by hand, and set the make on its merry way again. 
    1414 
    1515Now I run into my real problem. It goes to build genprimopcode and doesn't know how to do it. I check utils/genprimopcode and indeed there are no .hc files in there. I jump back to my other tree (the one that produced the .hc files) and manually (guessing on the ghc command-line) ask it to produce all the .hc files for me, first calling alex and happy for the grammar. I copy these .hc files over and resume the build. It happily accepts my .hc files, but then when it goes to link genprimopcode, I get a ''massive'' list of missing symbols. These included things like: 
    16  
     16{{{ 
    1717_base_GHCziShow_showSignedInt1_closure 
    1818_stg_CAF_BLACKHOLE_info 
    1919_integerzmgmp_GHCziIntegerziType_Szh_static_info 
     20}}} 
     21So this seems to imply that it's trying to build an executable for genprimopcode, and it wants the rts (surprise), base, and integer-gmp linked to it. However, the command-line used to link genprimopcode is: 
     22{{{ 
     23"gcc" -o utils/genprimopcode/dist/build/tmp/genprimopcode  -O -m64 -g -O0 -DNO_REGS -DUSE_MINIINTERPRETER            utils/genprimopcode/dist/build/Lexer.o utils/genprimopcode/dist/build/Main.o utils/genprimopcode/dist/build/ParserM.o utils/genprimopcode/dist/build/Parser.o utils/genprimopcode/dist/build/Syntax.o  
     24}}} 
     25... no linker flags at all, beyond the .o files! I'm not sure how this is supposed to ever link correctly with no rts or libraries. So I take that command-line for gcc and add to it from my 64-bit build tree until I get it to link (it ended up being a massive command-line, so I won't include it here). My built `genprimopcode` seemed to work, and displayed the help message when I ran it, but when I actually piped real primop specs into it, it segfaulted (in iconv, somehow). 
    2026 
    21 So this seems to imply that it's trying to build an executable for genprimopcode, and it wants the rts (surprise), base, and integer-gmp linked to it. However, the command-line used to link genprimopcode is: 
     27I gave up on making my own `genprimopcode`, and under the assumption that it wasn't excessively platform-dependent, I asked someone to give me the various `genprimopcode` from their linux x86_64 platform. This may have been misguided but I don't know enough about the process to know better. Anyway, with these files, it gave up on trying to build `genprimopcode` and went along happily through the build. 
    2228 
    23 "gcc" -o utils/genprimopcode/dist/build/tmp/genprimopcode  -O -m64 -g -O0 -DNO_REGS -DUSE_MINIINTERPRETER            utils/genprimopcode/dist/build/Lexer.o utils/genprimopcode/dist/build/Main.o utils/genprimopcode/dist/build/ParserM.o utils/genprimopcode/dist/build/Parser.o utils/genprimopcode/dist/build/Syntax.o  
     29In the final linkage step for stage2, producing the final ghc binary, I got another massive linker error. Again, I tinkered with its command-line until I got it to link correctly (lots of strange things missing there too, including the `PrelIOUtils.o` which I had to link in myself for some reason, and something defining `__hscore_long_path_size`, which I wrote a simple c file for).  
    2430 
    25 ... no linker flags at all, beyond the .o files! I'm not sure how this is supposed to ever link correctly with no rts or libraries. So I take that command-line for gcc and add to it from my 64-bit build tree until I get it to link (it ended up being a massive command-line, so I won't include it here). My built genprimopcode seemed to work, and displayed the help message when I ran it, but when I actually piped real primop specs into it, it segfaulted (in iconv, somehow). 
    26  
    27 I gave up on making my own genprimopcode, and under the assumption that it wasn't excessively platform-dependent, I asked someone to give me the various genprimopcode from their linux x86_64 platform. This may have been misguided but I don't know enough about the process to know better. Anyway, with these files, it gave up on trying to build genprimopcode and went along happily through the build. 
    28  
    29 In the final linkage step for stage2, producing the final ghc binary, I got another massive linker error. Again, I tinkered with its command-line until I got it to link correctly (lots of strange things missing there too, including the PrelIOUtils.o which I had to link in myself for some reason, and something defining __hscore_long_path_size, which I wrote a simple c file for).  
    30  
    31 So anyway, the resulting ghc, somewhat unsurprisingly, segfaulted immediately (in Data.List.last, for what it's worth). ghc +RTS --info did work however, and printed out the expected stuff, so not everything was broken. 
     31So anyway, the resulting ghc, somewhat unsurprisingly, segfaulted immediately (in Data.List.last, for what it's worth). `ghc +RTS --info` did work however, and printed out the expected stuff, so not everything was broken. 
    3232 
    3333So anyway, I'm sorry for this rambling "bug report" but I'm not sure what to do, and I've been through the above process (with minor variations and experiments) about 5 times so far, so I'm pretty sure I'm following the instructions correctly.