... | @@ -41,7 +41,10 @@ Linking the transitive closure as in the static case works for the other cases t |
... | @@ -41,7 +41,10 @@ Linking the transitive closure as in the static case works for the other cases t |
|
## GHCi with System Runtime Linker and Loader (RTLD)
|
|
## GHCi with System Runtime Linker and Loader (RTLD)
|
|
|
|
|
|
|
|
|
|
An object file must be compiled as position independent code (`-fPIC`). Then a temporary dynamic library is produced by `ld` with no other inputs. Undefined symbols are ignored.
|
|
SM: are you talking about the current implementation or your proposal here?
|
|
|
|
|
|
|
|
|
|
|
|
An object file must be compiled as position independent code (`-fPIC`). Then a temporary dynamic library is produced by `ld` with no other inputs (SM: this is not the case currently). Undefined symbols are ignored.
|
|
|
|
|
|
|
|
|
|
Link all temporary dynamic libraries and all packages loaded and all command line libraries into one large dummy dynamic library. The order on the link command line must be observed so it is possible to override symbols defined in a library loaded earlier. The order is reverse loading order, i.e. most recently loaded first.
|
|
Link all temporary dynamic libraries and all packages loaded and all command line libraries into one large dummy dynamic library. The order on the link command line must be observed so it is possible to override symbols defined in a library loaded earlier. The order is reverse loading order, i.e. most recently loaded first.
|
... | @@ -50,10 +53,13 @@ Link all temporary dynamic libraries and all packages loaded and all command lin |
... | @@ -50,10 +53,13 @@ Link all temporary dynamic libraries and all packages loaded and all command lin |
|
Should it be possible to override a symbol defined in a Haskell package? In that case the order of packages and temporary dynamic libraries as one list is important.
|
|
Should it be possible to override a symbol defined in a Haskell package? In that case the order of packages and temporary dynamic libraries as one list is important.
|
|
|
|
|
|
|
|
|
|
Do we need to support static libraries in a dynamic GHCi?
|
|
Do we need to support static libraries in a dynamic GHCi? (SM: not necessarily)
|
|
|
|
|
|
|
|
|
|
|
|
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.)
|
|
|
|
|
|
|
|
|
|
Theoretically, in ELF there should be no difference between a statically linked and a dynamically linked GHCi.
|
|
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.
|
|
|
|
|
|
## GHCi with Haskell runtime linker (RTS)
|
|
## GHCi with Haskell runtime linker (RTS)
|
|
|
|
|
... | | ... | |