upgrading to 7.0.3 causes assembly errors

[Simon Marlow]

On 04/05/2011 22:38, Evan Laforge wrote:
> So I just upgraded to 7, and on compiling I got:
>
> /var/folders/++/+++c0U++6+0++4RjPqRgNE++8+c/-Tmp-/ghc88373_0/ghc88373_1.s:43:0:
>     suffix or operands invalid for `push'
>
> /var/folders/++/+++c0U++6+0++4RjPqRgNE++8+c/-Tmp-/ghc88373_0/ghc88373_1.s:47:0:
>     suffix or operands invalid for `push'
>
> ... etc.
>
> Some digging revealed that it was actually in the compilation of a
> *_stub.c file, and the underlying problem is thus:
>
> This is OS X 10.6.  For various reasons, my app is compiled 32 bit,
> and I'm explicitly passing '-optc-m32 -opta-m32 -optl-m32' to ghc.
> Previously, of course, this wasn't necessary since ghc always produced
> 32 bit code.  But now there seems to be an issue with flag order.
> When ghc wants to compile the stub, it runs:
>
> g++ -x c ./Ui/RulerC_stub.c -o broken.s -m64 -fno-stack-protector
> -fno-common -U __PIC__ -D__PIC__ -v -S -Wimplicit -O
> -D__GLASGOW_HASKELL__=700 -DTABLES_NEXT_TO_CODE -ggdb -m32 ... rest of
> my flags
>
> Then it wants to assemble it:
>
> /Developer/usr/bin/gcc -m32 -I./Ui -Ifltk -I. -c broken.s -o
> ./Ui/RulerC_stub.o -m64 -fno-stack-protector
>
> So it looks like when compiling, the user flags go last, overriding
> the new default -m64.  But when assembling, they go first, and are
> overidden.
>
> This seems like an easy fix, I imagine it's just constructing the
> cmdline inconsistently.  Is there a way for me to influence how it
> constructs the cmdline for gcc for stubs?  I mean, without recompiling
> ghc.  I'm supposed to be able to get ghc to compile 32 bit, right?

No, GHC compiles either for 32-bit or 64-bit, chosen when GHC is built. 
  You probably want to install the 32-bit version of GHC.

I'm not sure how this worked for you before...

Anyway, it looks like the argument ordering for the assembler has 
already changed in 7.2, so I think your particular issue should have 
gone away.

 > It
> also seems odd to me that it's compiled and assembled separately, but
> I suppose there must have been some reason for that.

I don't think there's a very good reason for it, we could probably 
change it.

 > I guess I should have upgraded sooner to catch this back when there
 > was a new ghc 7 release every week...

Yes, if you could check with the 7.2.1 release candidate when we put one 
out, that would be very helpful.

Cheers,
	Simon