[Git][ghc/ghc][master] compiler: remove unused GHC.Linker module

Marge Bot (@marge-bot) gitlab at gitlab.haskell.org
Thu Jan 25 05:28:15 UTC 2024



Marge Bot pushed to branch master at Glasgow Haskell Compiler / GHC


Commits:
0ac8f385 by Cheng Shao at 2024-01-25T00:27:48-05:00
compiler: remove unused GHC.Linker module

The GHC.Linker module is empty and unused, other than as a hack for
the make build system. We can remove it now that make is long gone;
the note is moved to GHC.Linker.Loader instead.

- - - - -


3 changed files:

- − compiler/GHC/Linker.hs
- compiler/GHC/Linker/Loader.hs
- compiler/ghc.cabal.in


Changes:

=====================================
compiler/GHC/Linker.hs deleted
=====================================
@@ -1,36 +0,0 @@
-module GHC.Linker
-   (
-   )
-where
-
-import GHC.Prelude ()
-   -- We need this dummy dependency for the make build system. Otherwise it
-   -- tries to load GHC.Types which may not be built yet.
-
--- Note [Linkers and loaders]
--- ~~~~~~~~~~~~~~~~~~~~~~~~~~
---
--- Linkers are used to produce linked objects (.so, executables); loaders are
--- used to link in memory (e.g., in GHCi) with the already loaded libraries
--- (ghc-lib, rts, etc.).
---
--- Linking can usually be done with an external linker program ("ld"), but
--- loading is more tricky:
---
---    * Fully dynamic:
---       when GHC is built as a set of dynamic libraries (ghc-lib, rts, etc.)
---       and the modules to load are also compiled for dynamic linking, a
---       solution is to fully rely on external tools:
---
---       1) link a .so with the external linker
---       2) load the .so with POSIX's "dlopen"
---
---    * When GHC is built as a static program or when libraries we want to load
---    aren't compiled for dynamic linking, GHC uses its own loader ("runtime
---    linker"). The runtime linker is part of the rts (rts/Linker.c).
---
--- Note that within GHC's codebase we often use the word "linker" to refer to
--- the static object loader in the runtime system.
---
--- Loading can be delegated to an external interpreter ("iserv") when
--- -fexternal-interpreter is used.


=====================================
compiler/GHC/Linker/Loader.hs
=====================================
@@ -109,6 +109,34 @@ import System.Win32.Info (getSystemDirectory)
 
 import GHC.Utils.Exception
 
+-- Note [Linkers and loaders]
+-- ~~~~~~~~~~~~~~~~~~~~~~~~~~
+--
+-- Linkers are used to produce linked objects (.so, executables); loaders are
+-- used to link in memory (e.g., in GHCi) with the already loaded libraries
+-- (ghc-lib, rts, etc.).
+--
+-- Linking can usually be done with an external linker program ("ld"), but
+-- loading is more tricky:
+--
+--    * Fully dynamic:
+--       when GHC is built as a set of dynamic libraries (ghc-lib, rts, etc.)
+--       and the modules to load are also compiled for dynamic linking, a
+--       solution is to fully rely on external tools:
+--
+--       1) link a .so with the external linker
+--       2) load the .so with POSIX's "dlopen"
+--
+--    * When GHC is built as a static program or when libraries we want to load
+--    aren't compiled for dynamic linking, GHC uses its own loader ("runtime
+--    linker"). The runtime linker is part of the rts (rts/Linker.c).
+--
+-- Note that within GHC's codebase we often use the word "linker" to refer to
+-- the static object loader in the runtime system.
+--
+-- Loading can be delegated to an external interpreter ("iserv") when
+-- -fexternal-interpreter is used.
+
 uninitialised :: a
 uninitialised = panic "Loader not initialised"
 


=====================================
compiler/ghc.cabal.in
=====================================
@@ -580,7 +580,6 @@ Library
         GHC.JS.JStg.Syntax
         GHC.JS.JStg.Monad
         GHC.JS.Transform
-        GHC.Linker
         GHC.Linker.Config
         GHC.Linker.Deps
         GHC.Linker.Dynamic



View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/0ac8f38538dd54e7fffc65856a4eff7de75359f7

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/0ac8f38538dd54e7fffc65856a4eff7de75359f7
You're receiving this email because of your account on gitlab.haskell.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20240125/7dcf373a/attachment-0001.html>


More information about the ghc-commits mailing list