AccelerateHS / AccelerateHS/accelerate
New-pipeline: GHCi no longer works
- Vorherrschende Sprache
- Haskell
- Sterne
- 1k
- Forks
- 135
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Beschreibung
**Description**
Attempting to start a GHCi session using `cabal repl` fails with errors like the following:
```
[ 56 of 155] Compiling Data.Array.Accelerate.Pattern.Ordering ( src/Data/Array/Accelerate/Pattern/Ordering.hs, interpreted )
ghc-9.4.8: ^^ Could not load 'accelerate_buffer_byte_size', dependency unresolved. See top entry above.
: error:
GHC.ByteCode.Linker: can't find label
During interactive linking, GHCi couldn't find the following symbol:
accelerate_buffer_byte_size
This may be due to you not asking GHCi to load extra object files,
archives or DLLs needed by your current session. Restart GHCi, specifying
the missing library using the -L/path/to/object/dir and -lmissinglibname
flags, or simply by naming the relevant files on the GHCi command line.
Alternatively, this link failure might indicate a bug in GHCi.
If you suspect the latter, please report this as a GHC bug:
https://www.haskell.org/ghc/reportabug
```
Function `accelerate_buffer_byte_size` is defined in `cbits/memory.c`. It is used in `Array.Buffer` (abridging module names for brevity), bound by function `memoryByteSize`, and used by functions `bufferFromPtr` and `liftBufferData`.
The `Pattern` modules all result in such errors. These modules are implemented using the `Pattern.TH` module, which imports `Smart`, which imports `Representation.Array`, which imports the above `Array.Buffer` module. I confirmed that the `Array.Buffer` module is being built before the `Pattern` modules.
The foreign dependencies in `Array.Buffer` are loaded using [`addForeignFilePath`](https://hackage-content.haskell.org/package/template-haskell-2.24.0.0/docs/Language-Haskell-TH-Syntax.html#v:addForeignFilePath), referencing note [`[linking to .c files]`](https://github.com/ivogabe/accelerate/blob/970ff19eed681451771884bd9357e492a4dbd892/src/Data/Array/Accelerate/Debug/Internal/Flags.hs#L221-L240) in `Debug.Internal.Flags`.
> We use Template Haskell to tell GHC which .c files need to be compiled for a particular module, rather than relying on Cabal as is traditional. Using Cabal:
>
> * loading Accelerate into GHCi only works *after* compiling the entire package (which defeats the purpose), presumably because the `.c` files are compiled last. This would often lead to errors such "can not find symbol `__cmd_line_flags`" etc.
>
> * Cabal would refuse to re-compile `.c` files when changing command line flags, see:
>
> * Linking problems also prevented us from using Template Haskell in some locations, because GHC was unable to load the project into the interpreter to run the splices.
>
> Note that for this fix to work in GHCi we also require modules using it to be loaded as object code.
I tried using Stack (`stack repl`), and it fails with the same errors.
I confirmed that the FFI in `Array.Buffer` (using `cbits/memory.c` and `cbits/alloc.cpp`) are the only new uses of `addForeignFilePath`; all other uses are in `master`. I confirmed that GHCi still works in `master`.
These new uses are probably failing due to some unfortunate interaction with Template Haskell in modules that depend on `Array.Buffer`. FFI and Template Haskell can be problematic!
**Steps to reproduce**
* Cabal: `cabal repl`
* Stack: `stack repl`
**Expected behaviour**
All modules should build and load.
**Your environment**
* Branch: [`new-pipeline`](https://github.com/ivogabe/accelerate/tree/new-pipeline)
* Commit: [`970ff19e`](https://github.com/ivogabe/accelerate/tree/970ff19eed681451771884bd9357e492a4dbd892)
* GHC: `ghc-9.4.8`
* Cabal: `3.18.1.0`
* Stack: `3.11.1`
* OS: Arch Linux (`Linux 7.2.3-arch1-2 x86_64`)
Beitragsleitfaden
Für dieses Repository ist kein Beitragsleitfaden indexiert
Bewertung
Dieses Issue wurde noch nicht bewertet.