On Sat, May 3, 2014 at 9:34 PM, Omari Norman
I had a look at deka. It seems you need to list the decContext.c and decQuad.c in the other order in the cabal file to make the .o files show up in the right order in the call to ghc (you can see it with cabal repl -v).
Indeed, flipping the two and adding -fPIC to cc-options: in the cabal file made cabal repl work. Thanks a bunch.
The version I'm working on now links in several more C object files and I'm having the same problem there; I am reading up on linkers and fiddling around with it.
What I figured out is that cabal and/or ghci need to have the C object files listed so that the earlier object files provide the symbols that are needed by the later object files. This is the opposite order one would expect with a linker, where it is generally best to list object files with undefined symbols first, and then list the libraries that provide those objects later. This sort of cycle fixes the problem: 1. Get error message 2. Use grep and nm to rummage around in dist/build/**/*.o to see what object file provides the missing symbol 3. Rearrange your c-sources to put the needed file earlier 4. Repeat The library I'm using has no circular dependencies, so I got it working this way. No -fPIC is needed. It seems the C object files are loaded statically and GHCi will not keep track of undefined symbols and wait to find them later. Why earlier versions did this is unclear; as the error message suggests I will file a bug. Thanks everybody for your help! --Omari