Opened 4 years ago

Closed 3 years ago

#3681 closed bug (fixed)

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

Reported by: nwn Owned by:
Priority: normal Milestone: 7.0.2
Component: hsc2hs Version: 6.12.1 RC1
Keywords: Cc: bos@…
Operating System: MacOS X Architecture: x86
Type of failure: Other Difficulty:
Test Case: Blocked By:
Blocking: Related Tickets:

Description

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"

Change History (14)

comment:1 Changed 4 years ago by 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.

comment:2 Changed 4 years ago by nwn

  • Summary changed from hsc2hs wrapper script ignores default flags to hsc2hs wrapper script throws away $HSC2HS_EXTRA's value when specified C compiler to use

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.

comment:3 Changed 4 years ago by 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.

comment:4 Changed 4 years ago by simonmar

  • Milestone set to 6.12.1
  • Priority changed from normal to high
  • Type of failure changed from None/Unknown to Other

comment:5 Changed 4 years ago by igloo

  • Owner set to igloo

comment:6 follow-up: Changed 4 years ago by igloo

  • Milestone changed from 6.12.1 to 6.14.1
  • Priority changed from high to normal

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.

comment:7 Changed 4 years ago by igloo

  • Owner igloo deleted

comment:8 Changed 4 years ago by bos

  • Cc bos@… added

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

comment:9 Changed 4 years ago by igloo

The above kludge patch is in 6.12.1.

comment:10 Changed 3 years ago by igloo

  • Milestone changed from 7.0.1 to 7.0.2

comment:11 Changed 3 years ago by maeder

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

comment:12 Changed 3 years ago by igloo

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

comment:13 Changed 3 years ago by 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 "

comment:14 in reply to: ↑ 6 Changed 3 years ago by maeder

  • Resolution set to fixed
  • Status changed from new to closed

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.

Note: See TracTickets for help on using tickets.