Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
GHC
GHC
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 4,395
    • Issues 4,395
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 379
    • Merge Requests 379
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell Compiler
  • GHCGHC
  • Wiki
  • linking haskell

linking haskell · Changes

Page history
Edit LinkingHaskell authored Jan 26, 2016 by Simon Marlow's avatar Simon Marlow
Hide whitespace changes
Inline Side-by-side
Showing with 5 additions and 1 deletion
+5 -1
  • linking-haskell.md linking-haskell.md +5 -1
  • No files found.
linking-haskell.md
View page @ 0b4a7aef
......@@ -63,7 +63,11 @@ Should it be possible to override a symbol defined in a Haskell package? In that
Do we need to support static libraries in a dynamic GHCi? (SM: not necessarily) (PT: Good!)
Theoretically, in ELF there should be no difference between a statically linked and a dynamically linked GHCi. (SM: you need to elaborate here. There are big differences between the two: they load different libraries, use different linkers, etc.) (PT: The current situation is GHCi dynamically linked the use system linker, GHCi statically linked use RTS linker. I think at least on ELF systems you could have a statically linked GHCi and still use the system linker to load dynamic Haskell libraries. Is there anything in the Haskell runtime that would prevent that?)
Theoretically, in ELF there should be no difference between a statically linked and a dynamically linked GHCi.
- SM: you need to elaborate here. There are big differences between the two: they load different libraries, use different linkers, etc.)
- PT: The current situation is GHCi dynamically linked the use system linker, GHCi statically linked use RTS linker. I think at least on ELF systems you could have a statically linked GHCi and still use the system linker to load dynamic Haskell libraries. Is there anything in the Haskell runtime that would prevent that?
- SM: On Windows we can't mix dynamic and static Haskell code on the same runtime because there are representation differences. On ELF systems the symbols of the RTS have to be exposed to the dynamic linker, so if the RTS were static you would at the very least have to link it with `--export-dynamic` when linking GHC.
SM: We now have [RemoteGHCi](remote-gh-ci), which means that it will become irrelevant whether GHCi itself is dynamically linked or not, and we'll be able to choose when we start GHCi whether we use dynamic linking or not. You can try this out: `ghci -fexternal-interpreter -static` uses static linking, and `ghci -fexternal-interpreter -dynamic` uses dynamic linking. (PT: I would still like to get dynamic linking to work for platforms where we don't have an RTS linker but still want a statically linked GHCi so we can avoid the overhead of creating a separate process. If it cannot be done at least I would like to understand why.)
......
Clone repository Edit sidebar
  • All things layout
  • AndreasK
  • AndreasPK
  • Building GHC on Windows with Stack protector support (SSP) (using Make)
  • CAFs
  • CafInfo rework
  • Compiling Data.Aeson Error
  • Contributing a Patch
  • Core interface section
  • Dead Code
  • Delayed substitutions
  • Developing Hadrian
  • Documentation Style Guide
  • Doubleton Arrays
  • Errors as (structured) values
View All Pages