On Sat, May 3, 2014 at 10:40 AM, Niklas Haas wrote:

Have you tried cleaning the entire build tree with `cabal clean` or just getting rid of the temporary files in general?

Yes, multiple times. "cabal clean" and "git clean" both. Re-running "cabal repl" then automatically configures the package again and compiles all 40 of my modules, and then fails with the link error.

On Sat, May 3, 2014 at 11:42 AM, Johan Tibell wrote:

This might be due to using an older cabal (i.e. 1.16) to build part of the packages that are now installed in ~/.ghc. If you blow away that directory (and reinstall your user-installed packages) that might help.

This package doesn't depend on any Haskell libraries that don't ship with GHC. Doing rm -rf ~/.ghc && rm -rf dist && cabal repl doesn't fix anything--cabal repl still doesn't work with GHC 7.8.2, but works with 7.6.3. I do notice that under GHC 7.6.3, it seems that ghci itself links the C object files and then the .hs files are interpreted, while under 7.8.2 it seems that the .hs modules are being built before ghci even starts up. Might this problem be arising because 7.8 switched to the system linker? I don't know enough about linkers or about how GHC does linking to make an informed guess.

On Sat, May 3, 2014 at 1:44 PM, Niklas Haas wrote:

I would try `cabal clean && cabal configure && cabal build && cabal repl`.

I tried rm -rf ~/.ghc && rm -rf dist && cabal clean && cabal configure && cabal build && cabal repl Same problem. I also tried downgrading to cabal-1.18.0.3; same problem with GHC 7.8.2.

Hi Adam, On Sat, May 3, 2014 at 2:23 PM, adam vogt wrote:

I think I've seen what might be the same issue. Could you try adding a cc-options: -fPIC like: https://github.com/aavogt/HOpenCV/blob/master/HOpenCV.cabal#L83 ?

Now I get Loading object (static) dist/build/decnumber/src/decDouble.o ... ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc414_0/ghc414_1.so: undefined symbol: BCD2DPD Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Thanks, Omari

sounds like you have a stale / cabal 1.16 style ~/.cabal/config could you do "mv ~/.cabal/config ~/.cabal/config-old ; cabal update " then rebuild the universe? On Sat, May 3, 2014 at 4:53 PM, adam vogt wrote:

On Sat, May 3, 2014 at 2:58 PM, Omari Norman wrote:

...

Hi Adam,

On Sat, May 3, 2014 at 2:23 PM, adam vogt wrote:

...

I think I've seen what might be the same issue. Could you try adding a cc-options: -fPIC like: https://github.com/aavogt/HOpenCV/blob/master/HOpenCV.cabal#L83 ?

Now I get

Loading object (static) dist/build/decnumber/src/decDouble.o ... ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc414_0/ghc414_1.so: undefined symbol: BCD2DPD

Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug

Hi Omari,

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).

If anything it is odd that ghc-7.6 accepts the objects in the "wrong" order.

Regards, Adam _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

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.

On Sat, May 3, 2014 at 10:32 PM, Omari Norman wrote:

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.

My mistake - in addition, you do need to have the cc-options: -fPIC in the .cabal file. Bug here: http://ghc.haskell.org/trac/ghc/ticket/9074