[GHC] #10974: Fix SysTools.readElfSection on platforms where "readelf" have different name

[GHC]

#10974: Fix SysTools.readElfSection on platforms where "readelf" have different
name
-------------------------------------+-------------------------------------
        Reporter:  ony               |                Owner:
            Type:  bug               |               Status:  patch
        Priority:  normal            |            Milestone:  8.0.1
       Component:  Compiler          |              Version:  7.10.2
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  Other             |            Test Case:
                                     |  driver/recomp011
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D1326
       Wiki Page:                    |  Phab:D1335
-------------------------------------+-------------------------------------

Comment (by ony):

 Replying to [comment:7 hsyl20]:
 > Is there a way to use Data.Binary.Get in Systools? We could totally
 avoid using readelf and it should be faster too (no fork, no parsing, no
 need to use String).
 `Data.Binary.Get` is also monad parser library but for bytestrings.
 Writing yet another ELF-file parser but pure sounds interesting, but
 ineffective (better to spend that effort on something else).
 I do agree that using `libelf` might be faster. But I also like idea that
 `ghc` requires only `binutils`. Adding more dependency on something while
 we can get the same functionality with existing dependency looks bad for
 me.

 Replying to [comment:8 thomie]:
 > Add `binary` to `Build-Depends` in `compiler/ghc.cabal.in` (and
 `compiler/ghc.cabal`, so you don't have to rerun configure).
 This might be true for release tar-balls, but not for source code
 repository which should always go through `autoreconf` (`perl boot`) and
 `configure` to generate from files from their `.in`. And that's described
 in both `README.md` and `HACKING.md`.
 Note that `compiler/ghc.cabal` is in ignores where it should be. Though
 file is committed into repo - which is wrong. Probably some-one did that
 by mistake and/or when .gitignore entry were added no-one removed it.

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