On 14 October 2004 10:13, John Meacham wrote:
It's too late for 6.2.2, unless it's a 1-line fix. I don't think it is, because it won't be self-hosting without some more work in the build system.
;diff package.conf.backup package.conf # /usr/lib/ghc-6.2.1 2:06AM john@momenergy 1 12c12 < extra_ghc_opts = [], ---
extra_ghc_opts = ["-optc-m32", "-opta-m32", "-optl-m32"],
well, it did turn out to be a one-line fix :) but perhaps this isn't the proper way to do it, it does seem to have solved the problem for me though.
That's not really a "fix". It's a patch for the i386 distribution to make it work on on x86_64 platform, but it doesn't let you build GHC on that platform, for example. For that, some (probably small) changes to the build system would be required. I imagine you would do something like: ./configure --build=x86_64-unknown-linux --host=i386-unknown-linux and the build system picks up the difference between $BuildArch and $HostArch and adds the -m32 flags. Something like that.
The interesting bit will be doing the native code generator, but you should start from the new NCG in 6.4 if you're interested in working on that. Adding SSE support would be great.
Yes, I am looking at that code now.
Would it even be possible to have the same ghc binary have multiple target architectures? it seems that some stuff ends up hardcoded in various places after the ./configure of ghc.
Certainly compiling multiple native code generators into the compiler is possible in principle, but would require some work. That's certainly not the end of the story though: GHC expects certain constants to be "constant", including the size of a word on the target architectre. Abstracting this would be rather difficult. However, building a cross-compiler is probably more feasible. Some work involved definitely, but feasible. Cheers, Simon