Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • GHC GHC
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 4,826
    • Issues 4,826
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 443
    • Merge requests 443
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
    • Value stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #18651

Closed
Open
Created Sep 04, 2020 by Sylvain Henry@hsyl20Developer

Dubious rts-linking

I was working on refactoring linker stuff and I've found we rely on GHC's RTS ways in GHC.SysTools.linkDynLib:

    let -- This is a rather ugly hack to fix dynamically linked
        -- GHC on Windows. If GHC is linked with -threaded, then
        -- it links against libHSrts_thr. But if base is linked
        -- against libHSrts, then both end up getting loaded,
        -- and things go wrong. We therefore link the libraries
        -- with the same RTS flags that we link GHC with.
        dflags1 = if platformMisc_ghcThreaded $ platformMisc dflags0
          then addWay' WayThreaded dflags0
          else                     dflags0
        dflags = if platformMisc_ghcDebugged $ platformMisc dflags1
          then addWay' WayDebug dflags1
          else                  dflags1
-- [...]
    -- We don't want to link our dynamic libs against the RTS package,
    -- because the RTS lib comes in several flavours and we want to be
    -- able to pick the flavour when a binary is linked.
    -- On Windows we need to link the RTS import lib as Windows does
    -- not allow undefined symbols.
    -- The RTS library path is still added to the library search path
    -- above in case the RTS is being explicitly linked in (see #3807).
    let platform = targetPlatform dflags
        os = platformOS platform
        pkgs_no_rts = case os of
                      OSMinGW32 ->
                          pkgs
                      _ | gopt Opt_LinkRts dflags ->
                          pkgs
                        | otherwise ->
                          filter ((/= rtsUnitId) . unitId) pkgs
    let pkg_link_opts = let (package_hs_libs, extra_libs, other_flags) = collectLinkOpts dflags pkgs_no_rts
                        in  package_hs_libs ++ extra_libs ++ other_flags

So there are several things to note:

  1. we get the RTS ways via the settings file which is unnecessary as the RTS could expose them directly.
  2. we don't take into account the EventLog way in the Windows hack
  3. the new -flink-rts flag links GHC's rts (modulo EventLog), not the user specified one
  4. we only add ways for the Windows hack, we don't remove them. E.g. if -debug is set, but GHC isn't linked with debug RTS we will still link against a debug rts.
Edited Oct 02, 2020 by Sylvain Henry
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking