GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-03-27T12:44:05Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/24598Allow State# RealWorld in foreign import prim2024-03-27T12:44:05ZBen GamariAllow State# RealWorld in foreign import primCurrently programs such as:
```haskell
foreign import prim do_something :: State# RealWorld -> State# RealWorld
```
are rejected by GHC as `State# RealWorld` is not considered to be marshalable.
The rationale for this is rather question...Currently programs such as:
```haskell
foreign import prim do_something :: State# RealWorld -> State# RealWorld
```
are rejected by GHC as `State# RealWorld` is not considered to be marshalable.
The rationale for this is rather questionable:
```
Note [Marshalling void]
~~~~~~~~~~~~~~~~~~~~~~~
We don't treat State# (whose PrimRep is VoidRep) as marshalable.
In turn that means you can't write
foreign import foo :: Int -> State# RealWorld
Reason: the back end falls over with panic "primRepHint:VoidRep";
and there is no compelling reason to permit it
```
I have run into this multiple times in the past, most recently while fixing #24595, and the restriction seems rather indefensible.https://gitlab.haskell.org/ghc/ghc/-/issues/24535Allow foreign import declarations to be split into type definition and "imple...2024-03-19T15:25:03ZOleg GrenrusAllow foreign import declarations to be split into type definition and "implementation" importInstead of
```haskell
foreign import ccall unsafe "lookup3.h _jenkins_hashword" hashWord
:: Ptr Word32 -> CSize -> Word32 -> IO Word32
```
allow to write
```haskell
hashWord :: Ptr Word32 -> CSize -> Word32 -> IO Word32
foreign im...Instead of
```haskell
foreign import ccall unsafe "lookup3.h _jenkins_hashword" hashWord
:: Ptr Word32 -> CSize -> Word32 -> IO Word32
```
allow to write
```haskell
hashWord :: Ptr Word32 -> CSize -> Word32 -> IO Word32
foreign import ccall unsafe "lookup3.h _jenkins_hashword" hashWord
```
Note: we can get close by
```haskell
foreign import ccall unsafe "lookup3.h _jenkins_hashword"
hashWord :: Ptr Word32 -> CSize -> Word32 -> IO Word32
```
---
The motivation is that sometimes a function is natively implemented, sometimes it's a FFI import (depending on CPP, or through course of the project), and the vastly different syntax for function declaration is not convenient.https://gitlab.haskell.org/ghc/ghc/-/issues/24534Allow foreign imports to return ST actions2024-03-12T15:14:13ZOleg GrenrusAllow foreign imports to return ST actionsSome FFI usage is "pure" in the sense of ST, say you allocate some buffer (`MutableByteArray# s`) and pass it to the C function. I cannot use
```haskell
foreign import ccall "initMyStruct" c_initMyStruct :: MutableByteArray# s -> ST s (...Some FFI usage is "pure" in the sense of ST, say you allocate some buffer (`MutableByteArray# s`) and pass it to the C function. I cannot use
```haskell
foreign import ccall "initMyStruct" c_initMyStruct :: MutableByteArray# s -> ST s ()
```
which is a pity.https://gitlab.haskell.org/ghc/ghc/-/issues/24388Argument size computation for foreign ffi exports is likely wrong.2024-01-30T15:10:34ZAndreas KlebingerArgument size computation for foreign ffi exports is likely wrong.## Summary
In `GHC.HsToCore.Foreign.C:mkFExportCBits` we compute the size of arguments like this:
` aug_arg_size = sum [ widthInBytes (typeWidth rep) | (_,_,_,rep) <- aug_arg_info]`
While this is accurate as far as I can tell the onl...## Summary
In `GHC.HsToCore.Foreign.C:mkFExportCBits` we compute the size of arguments like this:
` aug_arg_size = sum [ widthInBytes (typeWidth rep) | (_,_,_,rep) <- aug_arg_info]`
While this is accurate as far as I can tell the only thing we use this for is if we use stdcall foreign exports we annotate the
function with the argument size.
I believe stdcall expects arguments to be padded to multiples of the platforms word size, however the current code
will give the exact size. So there might be a missmatch.
However as I understand it:
* stdcall is only a thing on 32bit
* It's basically only a thing on windows
* It's not the default calling convention
* I'm not sure the annotation is actually used/relevant for resolving symbols.
* If someone uses it they should easily be able to swap to another calling convention.
So I don't think it's worth investigating it further, but I figured I would document it in case anyone comes across this issue.https://gitlab.haskell.org/ghc/ghc/-/issues/24300`ConstPtr`'s name is misleading. Along with missing `T const *`type2024-03-27T00:59:52ZLemon`ConstPtr`'s name is misleading. Along with missing `T const *`type<!--
READ THIS FIRST: If the feature you are proposing changes the language that GHC accepts
or adds any warnings to `-Wall`, it should be written as a [GHC Proposal](https://github.com/ghc-proposals/ghc-proposals/).
Other features, appr...<!--
READ THIS FIRST: If the feature you are proposing changes the language that GHC accepts
or adds any warnings to `-Wall`, it should be written as a [GHC Proposal](https://github.com/ghc-proposals/ghc-proposals/).
Other features, appropriate for a GitLab feature request, include GHC API/plugin
innovations, new low-impact compiler flags, or other similar additions to GHC.
-->
## Motivation
`ConstPtr`'s name has tripped me up many times, `ConstPtr`'s name seems like it should be a `T * const` in C while in reality it's a `const T *`.
## Proposal
With this issue I propose repurposing `ConstPtr` to be `T * const` instead and adding `Const` or some similar named type to fill the role of `const T`. Along with this we can remove GHC treating const pointers and normal pointers as interchangeable because they're not.https://gitlab.haskell.org/ghc/ghc/-/issues/24290cAPI FFI linking issue: Multiple definitions message does not guide towards r...2024-01-10T16:13:18ZHécate MoonlightcAPI FFI linking issue: Multiple definitions message does not guide towards resolutionWhile using CApi I encountered this bug (original report [here](https://github.com/tree-sitter/haskell-tree-sitter/issues/307))
Error message:
```plaintext
Building executable 'capi-linker-error' for capi-linker-error-0.1.0.0...
[2 of ...While using CApi I encountered this bug (original report [here](https://github.com/tree-sitter/haskell-tree-sitter/issues/307))
Error message:
```plaintext
Building executable 'capi-linker-error' for capi-linker-error-0.1.0.0...
[2 of 2] Linking /tmp/capi-linker-error/dist-newstyle/build/x86_64-linux/ghc-9.9.20231111/capi-linker-error-0.1.0.0/x/capi-linker-error/build/capi-linker-error/capi-linker-error
/usr/bin/ld.gold: error: /tmp/capi-linker-error/dist-newstyle/build/x86_64-linux/ghc-9.9.20231111/capi-linker-error-0.1.0.0/x/capi-linker-error/build/capi-linker-error/capi-linker-error-tmp/app/foo.o: multiple definition of 'foo'
/usr/bin/ld.gold: /tmp/capi-linker-error/dist-newstyle/build/x86_64-linux/ghc-9.9.20231111/capi-linker-error-0.1.0.0/x/capi-linker-error/build/capi-linker-error/capi-linker-error-tmp/Main.o: previous definition here
collect2: error: ld returned 1 exit status
ghc-9.9.20231111: `gcc' failed in phase `Linker'. (Exit code: 1)
Error: [Cabal-7125]
Failed to build exe:capi-linker-error from capi-linker-error-0.1.0.0.
```
Minimal reproducer: https://github.com/brcha/capi-linker-error/
Using `foo.h` instead of `foo.c` is the fix, but the error message doesn't reflect this.https://gitlab.haskell.org/ghc/ghc/-/issues/24198ASAN support for pinned arrays2023-11-16T21:34:57ZBen GamariASAN support for pinned arraysDebugging memory soundness issues within polyglot applications can be incredibly difficult. In recent years, Address Sanitizer (ASAN) has largely supplanted dynamic translation approaches like `valgrind`.
We should likely add ASAN [pois...Debugging memory soundness issues within polyglot applications can be incredibly difficult. In recent years, Address Sanitizer (ASAN) has largely supplanted dynamic translation approaches like `valgrind`.
We should likely add ASAN [poisoning support](https://github.com/google/sanitizers/wiki/AddressSanitizerManualPoisoning) for pinned arrays, which are very likely to be used for FFI.https://gitlab.haskell.org/ghc/ghc/-/issues/23517GHC should accept FFI type wrapping State# RealWorld -> (# State# RealWorld, ...2023-06-20T14:33:25ZwinterlandGHC should accept FFI type wrapping State# RealWorld -> (# State# RealWorld, a #)<!--
READ THIS FIRST: If the feature you are proposing changes the language that GHC accepts
or adds any warnings to `-Wall`, it should be written as a [GHC Proposal](https://github.com/ghc-proposals/ghc-proposals/).
Other features, appr...<!--
READ THIS FIRST: If the feature you are proposing changes the language that GHC accepts
or adds any warnings to `-Wall`, it should be written as a [GHC Proposal](https://github.com/ghc-proposals/ghc-proposals/).
Other features, appropriate for a GitLab feature request, include GHC API/plugin
innovations, new low-impact compiler flags, or other similar additions to GHC.
-->
## Motivation
Recently I'm using `ST RealWorld` as an alternative IO monad to get rid of the `PrimMonad` constraint all over the place, it works pretty fine, with just one inconvenience: The type `ST RealWorld a` is not accepted as a return type of FFI imports. This is an unnecessary limitation.
## Proposal
Please accept any type wrapping around `State# RealWorld -> (# State# RealWorld, a #)` as an FFI return type.https://gitlab.haskell.org/ghc/ghc/-/issues/23456FFI: Incompatible pointer to integer conversion (only on darwin)2024-03-24T18:15:12ZbasvandijkFFI: Incompatible pointer to integer conversion (only on darwin)## Summary
Also described on discourse: https://discourse.haskell.org/t/ffi-incompatible-pointer-to-integer-conversion/6339
Let's say we have the file `FunPtrs.hs` with the following contents:
```haskell
{-# LANGUAGE ForeignFunctionIn...## Summary
Also described on discourse: https://discourse.haskell.org/t/ffi-incompatible-pointer-to-integer-conversion/6339
Let's say we have the file `FunPtrs.hs` with the following contents:
```haskell
{-# LANGUAGE ForeignFunctionInterface #-}
module FunPtrs where
import Foreign.Ptr
foreign import ccall "wrapper"
mk'callback :: IO (Ptr Int) -> IO (FunPtr (IO (Ptr Int)))
```
Compiling this (with both GHC-9.2.7 and GHC-9.6.1 on aarch64-darwin) yields the following warning:
```
ghc ./FunPtrs.hs
[1 of 1] Compiling FunPtrs ( /Users/bas/Downloads/FunPtrs.hs, /Users/bas/Downloads/FunPtrs.o )
/var/folders/7_/m1k33c791pz5v9nt2bdd89d80000gn/T/ghc89726_0/ghc_2.c:19:17: error:
warning: incompatible pointer to integer conversion assigning to 'ffi_arg' (aka 'unsigned long') from 'HsPtr' (aka 'void *') [-Wint-conversion]
|
19 | *(ffi_arg*)resp = cret;
| ^
*(ffi_arg*)resp = cret;
^ ~~~~
1 warning generated.
```
According to the [docs of `FunPtr`](https://hackage.haskell.org/package/base-4.18.0.0/docs/Foreign-Ptr.html#t:FunPtr):
> * the return type is either a marshallable foreign type or has the form `IO` t where `t` is a marshallable foreign type or `()`.
Isn't `Ptr Int` a marshallable foreign type? I thought that it was, so why am I getting this warning?
If I replace the return type to a non-pointer like `Int` the warning disappears.
The warning also doesn’t happen on x86_64-linux.
## Steps to reproduce
Compile the given program above.
## Expected behavior
I expected no warning to be thrown.
## Environment
* GHC version used: GHC-9.2.7 and GHC-9.6.1 (from nixpkgs-23.05)
Optional:
* Operating System: MacOS-13.4
* System Architecture: aarch64-darwinBen GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/23202JS: foreign CLOCK_REALTIME shouldn't use CApiFFI2023-12-16T19:51:29ZSylvain HenryJS: foreign CLOCK_REALTIME shouldn't use CApiFFIIn https://gitlab.haskell.org/ghc/packages/time/-/commit/226562b170eb2db5b2f4e6f5d9ffadf295bd5524, detection of the foreign value for CLOCK_REALTIME has been changed as follows to accommodate the Wasm backend:
```diff
-clock_REALTIME ::...In https://gitlab.haskell.org/ghc/packages/time/-/commit/226562b170eb2db5b2f4e6f5d9ffadf295bd5524, detection of the foreign value for CLOCK_REALTIME has been changed as follows to accommodate the Wasm backend:
```diff
-clock_REALTIME :: ClockID
-clock_REALTIME = #{const CLOCK_REALTIME}
+foreign import capi unsafe "time.h value CLOCK_REALTIME" clock_REALTIME :: ClockID
```
It broke the JS backend which doesn't support the CApiFFI.
The change must be conditionally reverted for the JS target and the submodule must be updated.https://gitlab.haskell.org/ghc/ghc/-/issues/23194Likely bug under Windows with mimimal reproducer2023-04-05T19:33:01ZdsamperiLikely bug under Windows with mimimal reproducer## Summary
Write a brief description of the issue.
For a mimimal FFI interface to R, values fetched from R in a library installed by
stack (compiled with ghc) are corrupted under Windows, while if everything (including the library
modu...## Summary
Write a brief description of the issue.
For a mimimal FFI interface to R, values fetched from R in a library installed by
stack (compiled with ghc) are corrupted under Windows, while if everything (including the library
module) is compiled with ghci there are no problems. A function in R.dll is called
successfully before attempting to read one of the corrupted variables, so this does
not seem to be a problem with delayed loading of the library, or relocation of the
library. There are no problems under Ubuntu Linux.
## Steps to reproduce
This Haskell package is a minimal reproducer (all unrelated code has been
stripped out of the hR package).
[hRbug-0.2.0.tar.gz](/uploads/492667c4739527065403b0636583bd6d/hRbug-0.2.0.tar.gz)
To install under Windows, be sure that R is in PATH, and that a UNIX/MSYS shell
is also in PATH (from Stack or Rtools). Then type 'stack install'
Setup.hs looks for R in PATH to do most of the configuration. As part of the setup the
script runhr is written to ~/.local/bin, which should be added to PATH.
There are two source files, a client (app/embeddedR.hs) and a library
(Rinternals/InternalsNilValue.hs). The client creates an embedded R instance,
calls a function in R.dll, and tries to read rNilValue, a variable that is
bound to R_NilValue in the library.
To run the app using the library that was installed
by stack, use 'stack exec embeddedR'. This will result in
a crash under Windows because rNilValue is not valid.
On the other hand, to compile everything (including the library) using ghci
use 'runhr app\embeddedR.hs'. Then start the app by running main. Everything
should work fine in this case.
Sometimes (not always) placing a trace like 'trace "PEEK"' before the peek in
InternalsNilValue.hs resolves the problem, perhaps because this changes the
exeuction order in some way.
## Expected behavior
The app should behave the same when compiled using ghc or ghci.
## Environment
* GHC version used: 9.2.7
Optional:
* Operating System: Windows 11
* System Architecture: Intel i9Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/23119Regression in FFI with wrapped callback2024-01-05T08:17:31ZsingpolymaRegression in FFI with wrapped callback## Summary
Regression between 9.0.2 and 9.2.5 affecting libxml-sax -- FFI with a wrapped function pointer that works on 9.0.2 and earlier (back to at least GHC7) as of at least 9.2.5 now when linked against the same library (libxml2) cr...## Summary
Regression between 9.0.2 and 9.2.5 affecting libxml-sax -- FFI with a wrapped function pointer that works on 9.0.2 and earlier (back to at least GHC7) as of at least 9.2.5 now when linked against the same library (libxml2) crashes, getting an uninitialized int and a null pointer where it normally expects a count and an array.
## Steps to reproduce
* ghcup to 9.2.5
* git clone https://git.sr.ht/~singpolyma/haskell-libxml-sax
* cabal test
## Expected behavior
Tests should pass.
## Environment
* GHC version used: 9.0.2 and 9.2.5
Optional:
* Operating System: Debian table and Debian Testing
* System Architecture: x86_649.2.8https://gitlab.haskell.org/ghc/ghc/-/issues/22705Cannot use ThreadId# with CApiFFI2023-01-20T21:12:40ZOleg GrenrusCannot use ThreadId# with CApiFFIIn `hashable` there is
```haskell
foreign import ccall unsafe "rts_getThreadId" getThreadId
:: ThreadId# -> CInt
```
code. If `ccall` is changed to `capi`, GHC panics:
```
<no location info>: error:
panic! (the 'impossible' ...In `hashable` there is
```haskell
foreign import ccall unsafe "rts_getThreadId" getThreadId
:: ThreadId# -> CInt
```
code. If `ccall` is changed to `capi`, GHC panics:
```
<no location info>: error:
panic! (the 'impossible' happened)
GHC version 9.4.3:
toCType
ThreadId#
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/GHC/Utils/Panic.hs:182:37 in ghc:GHC.Utils.Panic
pprPanic, called at compiler/GHC/HsToCore/Foreign/Decl.hs:764:17 in ghc:GHC.HsToCore.Foreign.Decl
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
cabal: Failed to build hashable-1.4.1.0 (which is required by
```https://gitlab.haskell.org/ghc/ghc/-/issues/22606Wasm backend testsuite failure: internal error: ffi_alloc_prep_closure failed: 42022-12-12T20:49:45ZCheng ShaoWasm backend testsuite failure: internal error: ffi_alloc_prep_closure failed: 4`T4221`, `T4038` fails with something like:
```
T4221: internal error: ffi_alloc_prep_closure failed: 4
(GHC version 9.5.20221211 for wasm32_unknown_wasi)
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
...`T4221`, `T4038` fails with something like:
```
T4221: internal error: ffi_alloc_prep_closure failed: 4
(GHC version 9.5.20221211 for wasm32_unknown_wasi)
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
error: Uncaught (in promise) RuntimeError: unreachable
at abort (wasm://wasm/01b05c4e:1:5923853)
at rtsFatalInternalErrorFn (wasm://wasm/01b05c4e:1:1511015)
at barf (wasm://wasm/01b05c4e:1:1511391)
at createAdjustor (wasm://wasm/01b05c4e:1:1684864)
at _blk_c1ID (wasm://wasm/01b05c4e:1:155586)
at StgRun (wasm://wasm/01b05c4e:1:1568771)
at scheduleWaitThread (wasm://wasm/01b05c4e:1:1554611)
at rts_evalLazyIO (wasm://wasm/01b05c4e:1:1499817)
at hs_main (wasm://wasm/01b05c4e:1:1510641)
at main (wasm://wasm/01b05c4e:1:166036)
*** unexpected failure for T4221(normal)
```
It's very likely hitting the internal limits about `libffi-wasm`. And I don't intend to bump limits to mitigate the failures here, the way forward would really be #22590.https://gitlab.haskell.org/ghc/ghc/-/issues/22590GHC should generate specialized libffi at link time in wasm backend2023-01-03T13:57:26ZCheng ShaoGHC should generate specialized libffi at link time in wasm backendCurrently, the wasm backend uses https://gitlab.haskell.org/ghc/libffi-wasm. The `libffi.a` linked into each Haskell program is compiled from auto-generated C code, and contains function/data sections for each single possible C function ...Currently, the wasm backend uses https://gitlab.haskell.org/ghc/libffi-wasm. The `libffi.a` linked into each Haskell program is compiled from auto-generated C code, and contains function/data sections for each single possible C function signature within a certain arity range (see readme's linked blog post for details). This is sufficient to kick start initial wasm support, but comes with a huge overhead in code size for certain use cases:
- `ffi_call` adds ~100KB to linked wasm. It's used by the bytecode interpreter and likely reachable if code uses GHC API.
- `ffi_alloc_prep_closure` adds ~4.8MB to linked wasm. It's used by dynamic C exports.
Although post-link optimization by `wasm-opt` can mitigate the code size increase, it's still far from satisfactory, and I don't think static analysis can identify unused paths in `libffi-wasm`'s generated code. We can do much better here.
Without going too much in details in either `libffi` or `wasm`, my proposed solution is roughly:
- We still link with `libffi.a`, and no need to change libffi adjustor logic. `libffi.a` still provides the same API, except it does not contain any generated code that covers each possible C function signature.
- `libffi-wasm` has a global state at runtime: a mapping from encoded C function signatures to their underlying handler functions.
- `ffi_call` or `ffi_alloc_prep_closure` will simply look up that mapping, and redirect the call to the handler function.
- At link time, we already know all possible C function signatures that we need to handle. So there will be some auto-generated C stub code that contain handler logic and register the handler into that mapping via ctor.
The only remaining issue is how to collect the C function signatures that `libffi-wasm` needs to support at GHC link time. This sounds like something that can be handled in interface files, but maybe we don't even need to. Whenever we desugar a dynamic C export, we add the handler logic we need in its stub code, that's it.https://gitlab.haskell.org/ghc/ghc/-/issues/22369JavaScript Backend: Implement foreign exports2022-12-20T10:27:51Zdoyougnujmy6342@gmail.comJavaScript Backend: Implement foreign exports### Description
Tracking issue to implement GHCJS's Foreign export.
### Impacted Tests
These have been skipped with `req_js_ffi_exports`, be sure to re-enable them and check each one off as you go:
- [ ] driver016 passes
- [ ] driver0...### Description
Tracking issue to implement GHCJS's Foreign export.
### Impacted Tests
These have been skipped with `req_js_ffi_exports`, be sure to re-enable them and check each one off as you go:
- [ ] driver016 passes
- [ ] driver017 passes
- [ ] driver019 passes
- [ ] driver027 passes
- [ ] driver028 passes
- [ ] driver034 passes
- [ ] driver035 passes
- [ ] driver044 passes
- [ ] driver045 passes
- [ ] driver061a passes
- [ ] driver061b passes
- [ ] driver070 passes
- [ ] driver071 passes
- [ ] driver081b passesSylvain HenryLuite StegemanJosh Meredithdoyougnujmy6342@gmail.comSylvain Henryhttps://gitlab.haskell.org/ghc/ghc/-/issues/22367JavaScript Backend: Implement compiling and linking c-sources with emscripten2022-10-27T14:41:17Zdoyougnujmy6342@gmail.comJavaScript Backend: Implement compiling and linking c-sources with emscripten### Description
The JS backend uses emscripten to compile any C files a library or program relies on. Unfortunately our linker does not handle the resulting object files yet and so these do not get linked into the final payload and we e...### Description
The JS backend uses emscripten to compile any C files a library or program relies on. Unfortunately our linker does not handle the resulting object files yet and so these do not get linked into the final payload and we error out in the Linker.
This ticket is the tracking ticket to implement this feature.
### Impacted Tests
We've skipped the following tests until this feature lands, be sure to check them off as you re-enable them. To generate the list search for `req_c` or do: `rg -B3 'req_c' | rg -e 'test\(\'.*\'' > 22367-tests`
* [ ] multipleHomeUnits_odir passes
* [ ] T5462Yes1 passes
* [ ] T5462Yes2 passes
* [ ] T20010 passes
* [ ] T20010-ghci passes
* [ ] RepPolyArrowCmd passes
* [ ] RepPolyArrowFun passes
* [ ] RepPolyBackpack1 passes
* [ ] RepPolyBackpack2 passes
* [ ] RepPolyBackpack3 passes
* [ ] RepPolyBackpack4 passes
* [ ] bkprun01 passes
* [ ] bkprun02 passes
* [ ] bkprun03 passes
* [ ] bkprun04 passes
* [ ] bkprun05 passes
* [ ] bkprun06 passes
* [ ] bkprun07 passes
* [ ] bkprun08 passes
* [ ] bkprun09 passes
* [ ] T13955 passes
* [ ] T15138 passes
* [ ] T15379 passes
* [ ] ccfail004 passes
* [ ] ccfail005 passes
* [ ] ccall_value passes
* [ ] capi_value_function passes
* [ ] UnsafeReenter passes
* [ ] ffi005 passes
* [ ] ffi015 passes
* [ ] T1679 passes
* [ ] T1288 passes
* [ ] T2276 passes
* [ ] T2469 passes
* [ ] T2594 passes
* [ ] fptrfail01 passes
* [ ] T4038 passes
* [ ] T4221 passes
* [ ] Capi_Ctype_002 passes
* [ ] ffi_parsing_001 passes
* [ ] T4012 passes
* [ ] T8083 passes
* [ ] T12134 passes
* [ ] T12614 passes
* [ ] T14624 passes
* [ ] T15933 passes
* [ ] T16650a passes
* [ ] T16650b passes
* [ ] T16650c passes
* [ ] T16650d passes
* [ ] PrimFFIInt8 passes
* [ ] PrimFFIWord8 passes
* [ ] PrimFFIInt16 passes
* [ ] PrimFFIWord16 passes
* [ ] PrimFFIInt32 passes
* [ ] PrimFFIWord32 passes
* [ ] T493 passes
* [ ] UnliftedNewtypesByteArrayOffset passes
* [ ] T17471 passes
* [ ] T19237 passes
* [ ] T4059 passes
* [ ] T7040 passes
* [ ] T10904 passes
* [ ] T11829 passes
* [ ] T16514 passes
* [ ] InitEventLogging passes
* [ ] T20199 passes
* [ ] cloneMyStack passes
* [ ] cloneMyStack_retBigStackFrame passes
* [ ] cloneThreadStack passes
* [ ] T11223_simple_link passes
* [ ] T11223_simple_link_lib passes
* [ ] T11223_simple_unused_duplicate_lib passes
* [ ] T11223_link_order_a_b_succeed passes
* [ ] T11223_link_order_b_a_succeed passes
* [ ] T11223_link_order_a_b_2_fail passes
* [ ] T11223_link_order_b_a_2_succeed passes
* [ ] T20137 passes
* [ ] T20735 passes
* [ ] T16846 passes
* [ ] T17920 passes
* [ ] T18527 passes
* [ ] load_short_name passes
* [ ] T12674w passes
* [ ] T12674 passes
* [ ] recomp004 passes
* [ ] T5594 passes
* [ ] T5402 passes
### Previous Work
- https://github.com/input-output-hk/plutus-apps/blob/f0e5fd6415f826ddbfbaae53f6db20a57779066e/js-bindgen/app/Main.hs
- https://github.com/input-output-hk/haskell.nix/blob/master/builder/Setup.ghcjs.hsSylvain HenryLuite StegemanJosh Meredithdoyougnujmy6342@gmail.comSylvain Henryhttps://gitlab.haskell.org/ghc/ghc/-/issues/22100ghc fails to link foreign library2022-10-19T20:04:51ZAlex Dghc fails to link foreign library## Summary
I was exploring ghc FFI features and got into the following trouble:
The project is building haskell shared lib using cabal `foreign library` feature.
Then, this library is linked against C application.
When final executable...## Summary
I was exploring ghc FFI features and got into the following trouble:
The project is building haskell shared lib using cabal `foreign library` feature.
Then, this library is linked against C application.
When final executable is invoked, getting this error:
```
newBoundTask: RTS is not initialised; call hs_init() first
```
Feels like some linking has gone wrong here. Maybe it is a cabal issue and it doesn't properly link Hs shared libs?
## Steps to reproduce
https://github.com/nineonine/foreign-lib-repro
## Expected behavior
haskell code can be called from c.
## Environment
* GHC version used: 9.0.2
* cabal 3.8.1.0
Optional:
* Operating System: macOS 12.5.1
* System Architecture: arm64Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/21932'FFI_DEFAULT_ABI' could not be recognized even if it is provided by ffitarget.h2022-08-15T13:45:27ZJason Wang'FFI_DEFAULT_ABI' could not be recognized even if it is provided by ffitarget.h## Summary
I've provided the ffi.h and its libs when `./configure`. But the hadrian compiler seems not to recognize the definition of `FFI_DEFAULT_ABI` in `ffitarget.h`.
```shell
error: In file included from _build/stage0/libraries/ghc...## Summary
I've provided the ffi.h and its libs when `./configure`. But the hadrian compiler seems not to recognize the definition of `FFI_DEFAULT_ABI` in `ffitarget.h`.
```shell
error: In file included from _build/stage0/libraries/ghci/build/GHCi/FFI_hsc_make.c:1:
FFI.hsc: In function 'main':
FFI.hsc:131:16: error: 'fFI_DEFAULT_ABI' undeclared (first use in this function); did you mean 'FFI_LAST_ABI'?
/opt/workload/build/ghc-9.2.3/_build/stage0/lib/template-hsc.h:45:10: note: in definition of macro 'hsc_const'
45 | if ((x) < 0) \
| ^
FFI.hsc:131:16: note: each undeclared identifier is reported only once for each function it appears in
/opt/workload/build/ghc-9.2.3/_build/stage0/lib/template-hsc.h:45:10: note: in definition of macro 'hsc_const'
45 | if ((x) < 0) \
|
```
## Steps to reproduce
This issue has the same background as issue 21921, so steps are similar to it.
Run `./configure` as below instead.
```shell
./configure \
AR_STAGE0=/usr/bin/ar \
CC_STAGE0=/usr/bin/gcc \
LD_STAGE0=/usr/bin/ld \
CC=${CROSS_TOOLS}/${CROSS_TARGET}-gcc \
CPP=${CROSS_TOOLS}/${CROSS_TARGET}-cpp \
LD=${CROSS_TOOLS}/${CROSS_TARGET}-ld \
NM=${CROSS_TOOLS}/${CROSS_TARGET}-nm \
OBJDUMP=${CROSS_TOOLS}/${CROSS_TARGET}-objdump \
STRIP=${CROSS_TOOLS}/${CROSS_TARGET}-strip \
RANLIB=${CROSS_TOOLS}/${CROSS_TARGET}-ranlib \
CLANG=${CROSS_TOOLS}/clang \
LLC=${CROSS_TOOLS}/llc \
OPT=${CROSS_TOOLS}/opt \
LDFLAGS=-L${BASEDIR}/cross-tools/ \
CPPFLAGS=-I${BASEDIR}/cross-tools/ \
--target=${CROSS_TARGET} \
--with-system-libffi=yes \
--with-ffi-includes=/opt/workload/cross-tools/target/usr/include/ \
--with-ffi-libraries=/opt/workload/cross-tools/target/usr/lib64
```
## Expected behavior
In `FFI.hsc`, 'fFI_DEFAULT_ABI' could be recognized as 'FFI_LAST_ABI', since it has been defined in `ffitarget.h`
## Environment
* GHC version used: 9.2.3
* Operating System: Fedoral Server 36
* System Architecture: x86_64https://gitlab.haskell.org/ghc/ghc/-/issues/21835cc-options not used when compiling capi wrapper files?2022-07-12T13:58:17ZMitchellSaladcc-options not used when compiling capi wrapper files?## Summary
`cc-options` don't appear to be passed to C compiler when compiling `capi` wrapper functions.
## Steps to reproduce
Main.hs
```haskell
{-# LANGUAGE CApiFFI #-}
{-# LANGUAGE ForeignFunctionInterface #-}
module Main where
...## Summary
`cc-options` don't appear to be passed to C compiler when compiling `capi` wrapper functions.
## Steps to reproduce
Main.hs
```haskell
{-# LANGUAGE CApiFFI #-}
{-# LANGUAGE ForeignFunctionInterface #-}
module Main where
import Foreign.C.Types
foreign import capi "hello.h foo" foo :: CInt
main :: IO ()
main = print foo
```
hello.h
```c
#ifdef HELLO
int foo();
#endif
```
hello.c
```c
#ifdef HELLO
int foo() { return 1; }
#endif
```
hello.cabal
```
cabal-version: 2.2
name: hello
version: 0
executable hello
build-depends: base
main-is: Main.hs
c-sources: hello.c
cc-options: -DHELLO
includes: hello.h
```
Output from `cabal run`:
```
[1 of 1] Compiling Main
/var/folders/0m/cpz59dyj3ts58crh9m1gbcyr0000gn/T/ghc58327_0/ghc_3.c:8:56: error:
error: implicit declaration of function 'foo' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
|
8 | HsInt32 ghczuwrapperZC0ZCmainZCMainZCfoo(void) {return foo();}
| ^
HsInt32 ghczuwrapperZC0ZCmainZCMainZCfoo(void) {return foo();}
^
1 error generated.
`gcc' failed in phase `C Compiler'. (Exit code: 1)
```
## Expected behavior
I expect to have some `int foo();` prototype in scope for the wrapper `ghc_3.c` file, so compilation should succeed and the program should print `1`.
The program does work using `ccall` (maybe that's obvious), and it also works if I don't hide the function prototype behind a `#ifdef HELLO` guard.
## Environment
* GHC version used: 9.2.2