#3472: Porting through .hc files broken
---------------------------------+------------------------------------------
Reporter: pumpkin | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 6.12 branch
Component: Build System | Version: 6.12.1 RC1
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Os: Unknown/Multiple
Architecture: Unknown/Multiple |
---------------------------------+------------------------------------------
Changes (by ksf):
* version: 6.11 => 6.12.1 RC1
* summary: Porting through .hc files seems broken (seems general but
parts of it may be osx-specific) => Porting
through .hc files broken
Comment:
{{{make[1]: *** No rule to make target `rts/dist/build/Apply.o', needed by
`rts/dist/build/libHSrts.a'. Stop.}}}
I've encountered the same, I moved all .hc files to .c files, including
AutoApply.hc, which lives in dist. Seems to work out fine.
the NO_REGS/MINI_INTERPRETER issue is fixed in 6.12.0-rc1.
the primopcodes are copied over from the host according to the port
process docs, but the build system doesn't get that they're already there
and tries to build genprimopcode, anyway. I nuked the respective make
rules, and stuff seems to work out fine (that is, it compiles).
I've also encountered various linker issues (and missing symbols
beforehand, as haiku e.g. doesn't come with siginfo_t), but I guess these
are quite normal while porting to a new platform. A stub for getlocale
won't hurt the system, too.
I've also experienced segfaults in Data.List.last, but can say that ghc
would have failed differently, anyway, due to wrong args etc.
However, there's two very, very important bits missing to the porting
process:
1) Hs*Config.h (those for the libraries) aren't taken from the target
system, but the host while generating .hc's (I'm looking into making the
build system eat them, the naive approach didn't work (made make error out
due to looping))
2) the intermediate .c files generated from .hsc files are compiled with
the host's headers (which leads to fun bugs like ghc being confused about
what consists a directory and what not, due to struct stat having a
different layout). This can either be fixed by moving the intermediate
files onto the target and compile+run them there (which is awkward), or
pre-processing them on the host using the target's headers, then
compiling+running them on the host (which is convenient, and should be
safe to do). Another possibility, of course, is to switch to c2hs, which
knows of cross-compiling.
I've also had issues with too big constants in .hc files, but instead of
investigating the source, I switched to a 32-bit chroot for my host.
I'm going to flag my other bug as a duplicate of this.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3472#comment:2>
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
