Bad Interaction between TemplateHaskell and FFI for cabal build

[ecaustin]

Here's an adaptation of Don Stewart's compiled constants example to demonstrate the issue:
cabal-example.

When the project is loaded into ghci via cabal repl everything works fine.
However, when compiled via cabal build the following error is produced:

Building constants-0.1...
Preprocessing library constants-0.1...
[1 of 2] Compiling Constants        ( Constants.hs, dist/build/Constants.o )
[2 of 2] Compiling Constants2       ( Constants2.hs, dist/build/Constants2.o )
dyld: lazy symbol binding failed: Symbol not found: _constant_cstring
  Referenced from: /var/folders/dv/5spsnmzd7r51hbp2q4lkjb6m0000gn/T/ghc78711_0/libghc_6.dylib
  Expected in: flat namespace

dyld: Symbol not found: _constant_cstring
  Referenced from: /var/folders/dv/5spsnmzd7r51hbp2q4lkjb6m0000gn/T/ghc78711_0/libghc_6.dylib
  Expected in: flat namespace

Trace/BPT trap: 5

Given that the code loads fine in GHCi, is there a flag, custom Setup.hs, or other workaround to get compilation to succeed?

As a note, this may or may not be related to an older cabal issue: #1738.

[23Skidoo]

Try adding TemplateHaskell to other-extensions.

[23Skidoo]

Related: #1562.

[ecaustin]

In my actual project I have TemplateHaskell listed in extensions.
I also tried adding TemplateHaskell to other-extensions to the minimal example I have linked above.
Neither had any impact on compilation.

Thanks for linking the other issue, I must have missed that in my search.

[ezyang]

Thank you for a working, reproducible test case. I think this is a duplicate of #1738? If you add cbits/constants.c -fPIC to the invocation of GHC, the program works, but I heard there were limitations to having GHC manage compilation of C files AND hs files at the same time (but I cannot remember / find the ticket) off hand.

[ecaustin]

Thanks for looking into this, Edward.

Is there any way to pass the additional, necessary flag for compilation using cabal?
Unlike the author of #1738, I have no issue with compiling all of the C files first as that code never calls back into Haskell.

I had actually attempted this with a custom Setup.hs, but I only got as far as getting compilation for the C code to succeed; GHC complained about not being able to find the resultant library.

[ezyang]

Here's a workaround I know will work: put the C FFI bits and function called from Haskell into a separate package, and then depend on that. Then TH should work.

There might be a less intrusive workaround but I can't think of any right now.

[ezyang]

Changing how we build these is tricky and a potentially BC-breaking change, so unless someone volunteers I don't think this will get fixed in the near future. Maybe we can give a warning when this might occur though.

[ecaustin]

Thanks again for looking into this Edward. This isn't a blocking issue for me, so I have no complaint against tabling this bug for now.

I'm out of cycles to work on "fun stuff" this fiscal year, but if I find the time to help contribute to a fix for this in the future I'll let you know.

[ezyang]

That would be much appreciated. :)