#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