[GHC] #9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...)

[GHC]

#9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against
`stg_CHARLIKE_closure'...)
-------------------------------------+-------------------------------------
        Reporter:  nomeata           |                   Owner:  nomeata
            Type:  bug               |                  Status:  infoneeded
        Priority:  high              |               Milestone:  7.12.1
       Component:  Compiler          |                 Version:  7.9
      Resolution:                    |                Keywords:
Operating System:  Unknown/Multiple  |            Architecture:
 Type of failure:  Building GHC      |  Unknown/Multiple
  failed                             |               Test Case:
      Blocked By:                    |                Blocking:
 Related Tickets:                    |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by slyfox):

 Replying to [comment:18 rwbarton]:
 > If we do so should we apply the options from `-optc-foo` when doing this
 detection?

 I think we need to ignore -optc during autodetection and should check only
 vanilla pgmC.
 It should simplify meaning of ghc -fPIC -optc-fno-PIC.
 I would say ghc -fno-PIC should disable PIC for both gcc/ghc even if fPIC
 is a default.

 > I was going to object that the C compiler options can vary between input
 files in a single compilation (with `OPTIONS_GHC`) though technically the
 same is true of the C compiler program and it looks like we don't
 currently handle that correctly either. Probably it would not be
 unreasonably difficult to redo the detection only when the program/options
 have actually changed.
 >
 > Does the Debian (or Fedora/Gentoo) build system have some extra magic
 that makes all invocations of gcc produce PIC/PIE by default? Otherwise
 `ghc -optl-fPIE -optl-pie -optl-Wl,-z,relro -optl-Wl,-z,now` is not going
 to get the job done in any case, and the build systems will have to learn
 about how to specify either `-fPIC` or `-optc-fPIC` to `ghc` even if we do
 this autodetection and it uses the C compiler options.

 Hardened gentoo patches gcc to default to -fPIC -fPIE -pie. Defaults
 there:
 {{{
 # gcc -dM -E - < /dev/null | grep -E -i 'pic|pie'
 #define __pie__ 2
 #define __PIE__ 2
 #define __pic__ 2
 #define __PIC__ 2
 }}}

 What bothers me is -optl-pie seems not to work even for -split-objs case
 on vanilla gcc/ghc:
 {{{
 $ echo 'main = print "hello"' > a.hs
 $ ghc --make -optl-pie -fPIC -optc-fPIC -dynamic a.hs -fforce-recomp
 [1 of 1] Compiling Main             ( a.hs, a.o )
 Linking a ...
 $ ghc --make -optl-pie -fPIC -optc-fPIC -dynamic a.hs -fforce-recomp
 -split-objs
 [1 of 1] Compiling Main             ( a.hs, a.o )
 /usr/lib/gcc/x86_64-pc-linux-gnu/5.1.0/../../../../x86_64-pc-linux-
 gnu/bin/ld: -r and -shared may not be used together
 collect2: error: ld returned 1 exit status
 }}}
 An evil corner case as we use ld for partial linking. Can be an argument
 for native
 fPIE/pie support in ghc.

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