#3472: Porting through .hc files seems broken (seems general but parts of it may
be osx-specific)
-----------------------------+----------------------------------------------
Reporter: pumpkin | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 6.11 | Severity: normal
Keywords: | Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
-----------------------------+----------------------------------------------
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.
I'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.
I've been treating the x86_64 unregistered build as a .hc port, so I
effectively partitioned my box into two machines, one with a gcc that
compiles to i386 by default and the other with one for x86_64. I follow
the instructions on the page above and first generate the headers
describing the 64-bit machine with the 64-bit compiler, then I copy them
into another ghc tree, switch the gcc to i386 default, and do a build that
keeps its .hc files. Most of it goes fine, and then I start getting
massive errors about the assembly output being incorrect (which should be
fine because all I want are the .hc files). So I follow the make -k and
ignore the errors (although this is rather nerve-wracking as instructions
saying "just ignore any errors" seem rather fragile). I then build the
tarball with all the .hc files in it and unpack it in the other tree.
Now, I switch the gcc back to default x86_64, and go through the rest of
the process described. My first issue is that the FB_ macro is inserting
--- BEGIN --- explicitly into my assembly. This feels odd, as I'm doing an
unregistered build. It seems that somehow the MINI_INTERPRETER macro and
NO_REGS aren't getting defined, so the pre-mangler stuff is getting
inserted into my assembly. I add -Ds for those to my build.mk and resume.
This goes smoothly for a while, and then I encounter an error:
make[1]: *** No rule to make target `rts/dist/build/Apply.o', needed by
`rts/dist/build/libHSrts.a'. Stop.
I 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.
Now 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:
_base_GHCziShow_showSignedInt1_closure
_stg_CAF_BLACKHOLE_info
_integerzmgmp_GHCziIntegerziType_Szh_static_info
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:
"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
... 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).
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.
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).
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.
So 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.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3472>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
