hsc2hs wrapper script throws away $HSC2HS_EXTRA's value when specified C compiler to use

[nwn]

hsc2hs wrapper script ignores default flags to build 32bit binary when specified C-compiler to use even if it was gcc.

This become a problem when building packages with Cabal. As usual, Cabal passes --cc=/path/to/gcc to hsc2hs. So default flags are ignored, built packages are broken.

I edited script to fix this problem. I think it's ugly fix, but it works.

#!/bin/sh
exedir="/Library/Frameworks/GHC.framework/Versions/612/usr/lib/ghc-6.12.0.20091121"
exeprog="hsc2hs"
executablename="$exedir/$exeprog"
datadir="/Library/Frameworks/GHC.framework/Versions/612/usr/share"
bindir="/Library/Frameworks/GHC.framework/Versions/612/usr/bin"
topdir="/Library/Frameworks/GHC.framework/Versions/612/usr/lib/ghc-6.12.0.20091121"
HSC2HS_EXTRA="--cflag=-m32 --lflag=-m32"
#!/bin/sh

tflag="--template=$topdir/template-hsc.h"
Iflag="-I$topdir/include/"

for arg do
    case "$arg" in
        *gcc)         break;;
        -c*)          HSC2HS_EXTRA=;;
        --cc=*)       HSC2HS_EXTRA=;;
        -t*)          tflag=;;
        --template=*) tflag=;;
        --)           break;;
    esac
done

exec "$executablename" "$tflag" $HSC2HS_EXTRA ${1+"$@"} "$Iflag"

[duncan]

Sorry, it's not clear to me from the description what the problem is exactly. What default flags?

Can you give a concrete example and what you expect to happen.

[nwn]

The default flags means $HSC2HS_EXTRA in the script. On OS X, ghc can only build 32 bit binary, so hsc2hs should be operated to build 32bit binary.

For example, when I install a package which will build some *.hsc files (e.g. network) with Cabal, I expect hsc2hs will be passed the flags to build 32bit binaries. But Cabal passes --cc flags to hsc2hs, so $HSC2HS_EXTRA's value becomes empty, hsc2hs goes wrong. Because gcc on OS X will build 64bit binary as default.

And I think this is the problem about the wrapper script. My wrapper script will ignore $HSC2HS_EXTRA only when specified C compiler to use is not gcc.

[duncan]

Ah yes ok. So the hsc2hs wrapper script is wrong because it drops the CC flags when the caller specifies where gcc is. Only if the caller does not specify the location of gcc will hsc2hs get called with the correct cc flags.

There are probably several places this could be fixed. Longer term it's probably not reasonable for hsc2hs to be hard-coded to a particular target. In principle it should be possible to call it for either 32 or 64bit modes on hosts that support it (or possibly to use a cross-compiler).

This suggests that perhaps it is the build managers (eg cabal) that should know which target is in use and then pass flags to tools as appropriate.

In the mean time, ghc only supports 32bit on OSX, so it's probably ok to have the HSC2HS_EXTRA flags be unconditional.

[igloo]

Fixed, for now, in HEAD and 6.12 by:

Tue Dec  1 04:47:16 PST 2009  Ian Lynagh <igloo@earth.li>
  * Don't set HSC2HS_EXTRA= when we get a --cc= flag; fixes trac #3681
  On OS X, we need to specify -m32 or -m64 in order to get gcc to
  build binaries for the right target. We do that by putting it in
  HSC2HS_EXTRA. When cabal runs hsc2hs, it passes a flag saying which
  gcc to use, so if we set HSC2HS_EXTRA= then we don't get binaries
  for the right platform. So for now we just don't set HSC2HS_EXTRA=
  but we probably want to revisit how this works in the future.

[bos]

So this will be fixed in 6.12.2, is that correct?

[igloo]

The above kludge patch is in 6.12.1.

[maeder]

Is this problem fixed? If not, would it solve ticket #4860, too?

[igloo]

The fix in an earlier comment is sufficient that this will not be the cause of #4860.

[maeder]

It seems the fix (not setting HSC2HS_EXTRA) caused #4860. Interestingly, for ghc-6.12.1 and ghc-6.12.3 my hsc2hs script contains:

HSC2HS_EXTRA="--cflag=-m32 --lflag=-m32"

(I cannot remember if I've changed something manually for ghc-6.12.3)

Whereas hsc2hs for ghc-7.0.1.20101215 contains just:

HSC2HS_EXTRA="--cflag=-fno-stack-protector "

[maeder]

It seems "-m32" got lost for some other reason in hsc2hs of ghc-7.0.1. In ghc-6.12.3 it is created during "make install".

Therefore I close this ticket.