Lift instance cause Cabal build error: unknown symbol with CFFI but Cabal repl works fine
- Dominant language
- Haskell
- Stars
- 1.7k
- Forks
- 750
- Avg merge
- 4d 3h
- Merged PRs (30d)
- 28
Description
**Describe the bug**
When building a Haskell-based Floating Point library for Clash that uses the mpfr library through the hmpfr binding, an error occurs during the cabal build process on both Windows and Linux. On Windows, the error indicates an unknown symbol (mpfr_add) from MPFR library, while on Linux, the error involves an undefined symbol (mpfr_custom_get_size_wrap) located in the chsmpfr.c file in cbits folder, preventing successful compilation. However, running cabal repl works fine without issues on both platforms.
**To Reproduce**
Steps to reproduce the behavior:
1. Clone the library
```
git clone https://github.com/yourcomrade/FloPoCoFloat
```
2. Install mpfr library (If don't have)
On Window with msys2:
```bash
pacman -S mingw-w64-clang-x86_64-mpfr
```
On Linux Ubuntu WSL
```
sudo apt install libmpfr6
sudo apt install libmpfr-dev
```
3. Navigate to Error_branch
```
git checkout Error_branch
```
4. Build project using cabal
5. Observe the build log error
Window:
```bash
ghc-9.8.2.exe: | D:\haskell\FloPoCoFloat2\FloPoCoFloat\dist-newstyle\build\x86_64-windows\ghc-9.8.2\FloPoCoFloat-0.1.0.0\build\Data\Number\MPFR\Arithmetic.o: unknown symbol `mpfr_add'
ghc-9.8.2.exe: Could not load Object Code D:\haskell\FloPoCoFloat2\FloPoCoFloat\dist-newstyle\build\x86_64-windows\ghc-9.8.2\FloPoCoFloat-0.1.0.0\build\Data\Number\MPFR\Arithmetic.o.
```
Linux
```bash
!!! systool:linker: finished in 19.90 milliseconds, allocated 10.151 megabytes
/home/minh/.ghcup/ghc/9.8.2/lib/ghc-9.8.2/bin/./ghc-9.8.2: symbol lookup error: /tmp/ghc382583_0/libghc_15.so: undefined symbol: mpfr_custom_get_size_wrap
```
**Expected behavior**
The expected behavior is for the cabal build to compile the project successfully without any unknown symbol errors related to mpfr_add on Windows or mpfr_custom_get_size_wrap on Linux. If the cabal build fail, then cabal repl shouldn't work. But this case doesn't happen.
**System information**
- Operating system: Window 11, Ubuntu WSL 5.15
- `cabal 3.10.3`, `ghc 9.8.2` versions, `gcc 11.4` in WSL
**Additional context**
I am building a floating point library for Clash that uses FloPoCo, a floating point core generator. The library uses the FloPoCo floating point format, defined as FoFloat, and integrates with the MPFR library via the hmpfr Haskell bindings. The goal is to provide accurate floating-point operations in Clash-generated HDL code by simulating the floating-point operations in software.
The following code causes the error during the build process:
```haskell
data FoFloat (wE :: Nat) (wF :: Nat) (rndMode :: M.RoundMode) =
FoFloat { ext :: (BitVector 2)
, sign :: Bit
, exponentVal :: (BitVector wE)
, fractionalVal :: (BitVector wF)
, rndModeVal :: (Proxy rndMode)
}
deriving (Generic, Typeable, Show, BitPack, Eq, NFDataX, ShowX, Lift)
deriving instance (Lift (Proxy a))
deriving instance (NFDataX (Proxy a))
deriving instance (ShowX (Proxy a))
-- Example usage that triggers the error:
ta = $(lift (1.2 :: FoFloat 4 11 M.Near))
```
The issue occurs during the cabal build step when compiling the FloPoCoFloat library.
- On Windows, the error involves mpfr_add, which cannot be found in the object code during the build process.
- On Linux, the error involves mpfr_custom_get_size_wrap, resulting in a symbol lookup failure when attempting to load shared libraries during the build.
Despite these errors, the cabal repl command works as expected on both platforms and successfully loads the proto.hs file located in src folder.
The error appears to be related to the interaction between the hmpfr Haskell bindings and the C-based MPFR library, with missing or improperly linked symbols.
The issue is consistent across both platforms but manifests with different symbols.
GitHub repository with error branch: [FloPoCoFloat - Error_branch](https://github.com/yourcomrade/FloPoCoFloat/tree/Error_branch)
Contributor guide
Assessment
This issue has not been assessed yet.