[GHC] #9421: Problems and workarounds when installing and using a 32bit GHC on 64bit Linux machine

[GHC]

#9421: Problems and workarounds when installing and using a 32bit GHC on 64bit
Linux machine
-------------------------------------+-------------------------------------
              Reporter:              |            Owner:  MikolajKonarski
  MikolajKonarski                    |           Status:  new
                  Type:  bug         |        Milestone:
              Priority:  normal      |          Version:  7.8.3
             Component:  Compiler    |         Keywords:
            Resolution:              |     Architecture:  x86_64 (amd64)
      Operating System:  Linux       |       Difficulty:  Unknown
       Type of failure:  Installing  |       Blocked By:
  GHC failed                         |  Related Tickets:
             Test Case:              |
              Blocking:              |
Differential Revisions:              |
-------------------------------------+-------------------------------------

Comment (by MikolajKonarski):

 Regarding the zlib problem (wrong hsc2hs options when comping zlib for
 32bits on 64 bits),
 https://ghc.haskell.org/trac/ghc/ticket/3400#comment:16 (further changed
 in #7760)
 could not possibly help, because it only passes options to hsc2hs when
 compiling ghc

 https://github.com/ghc/hsc2hs/blob/4a0f67704d89712f8493a0c7eccffa9243d6ef09/ghc.mk#L30

 and passes the options not from ghc but from CONF_* variables.

 I guess hsc2hs links to the correct version of libz after all, but the
 name it uses is a bit different, even though equivalent, to the name the
 internal checks in the haskell package zlib expect and so zlib panics. If
 that's the case I could file a bug report agains zlib. But if we go the
 route of automatically adding m32 to all invocations whenever we detect
 the 32bits on 64 bits scenario, fixes to zlib (nor to gtk) won't be needed
 and possibly some other problems, with yet different packages, will be
 avoided.

 For the record, the faulty call to hsc2hs looks rather reasonable, except
 for the mention of Dx86_64_BUILD_ARCH (are our i386 GHCs releases cross-
 compiled?), but even that should not cause any problems normally, I
 suppose.

 {{{
 ("/home/mikolaj/local/bin/hsc2hs",["--cc=/usr/bin/gcc","--
 ld=/usr/bin/gcc",
 "--cflag=-D__GLASGOW_HASKELL__=708","--cflag=-Dlinux_BUILD_OS=1",
 "--cflag=-Dx86_64_BUILD_ARCH=1","--cflag=-Dlinux_HOST_OS=1",
 "--cflag=-Di386_HOST_ARCH=1","--cflag=-Idist/build/autogen",
 "--cflag=-include","--cflag=dist/build/autogen/cabal_macros.h",
 "--lflag=-lz", [...], "--
 lflag=-L/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/rts-1.0",
 "--
 lflag=-Wl,-R,/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/rts-1.0","
 --lflag=-lm",
 "--lflag=-lrt","--
 lflag=-ldl","-o","dist/build/Codec/Compression/Zlib/Stream.hs",
 "Codec/Compression/Zlib/Stream.hsc"])
 }}}

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9421#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler