GHCi runtime linker issue when using FFI declarations

This is a known limitation of dynamic linking object files in the bytecode interpreter, GHCi.

If you load compiled code that was statically linked against a given C object, and then also interpret some Haskell on the fly that also refers via the FFI to the same C object, the runtime linker will be forced to load the C object dynamically.

Now you have two versions of the C symbol in your address space, and failures ensue.

You must either interpret everything under GHCi mode, or abandon using GHCi for this process. For some OS linkers, you can expose the statically linked symbol table via the dynamic table, (the -x flag).

Leave a Comment

Hata!: SQLSTATE[HY000] [1045] Access denied for user 'divattrend_liink'@'localhost' (using password: YES)