Libraries that use Template Haskell cannot use atomic-primops (cas symbol problem) about haskell-lockfree HOT 7 CLOSED

Yes, I got the same error with your reproducer.

Aha, it looks like GHCI provides a third scenario beyond "ghc" and "ghc -threaded".

In fixing Issue #8, I made sure that duplicate versions of the relevant functions were there to support normal compilation/linking with or without -threaded. Actually, in both of THOSE cases "cas" is available, but the other barrier functions are not. Yet it looks like in the GHCI case "cas" is not available.

I think the fix can simply be extended to cover this.

from haskell-lockfree.

Ugh, working on it. Past the 'cas' error and now getting this:

Loading package atomic-primops-0.4 ... linking ... ghc: /u/rrnewton/.cabal/lib/atomic-primops-0.4/ghc-7.6.3/HSatomic-primops-0.4.o: unknown symbol `stg_MUT_VAR_CLEAN_info'

Also, I'd welcome a pull request with a simplified version of the reproducer in it. Or any other tests you have that are giving problems.

from haskell-lockfree.

I'm afraid I'm stumped on this until I dig a bit more into how GHCI works. The library has a bunch of undefined symbols which need to be satisfied by the RTS.

             U base_GHCziBase_zpzp_info
             U base_GHCziForeignPtr_ForeignPtr_con_info
             U base_GHCziForeignPtr_MallocPtr_con_info
             U base_GHCziForeignPtr_mallocForeignPtr3_closure
             U base_GHCziSTRef_STRef_con_info
             U base_GHCziSTRef_readSTRef1_info
             U base_GHCziShow_DZCShow_static_info
             U base_GHCziShow_showListzuzu_info
             U dirty_MUT_VAR
             U fetch_and_add_word
             U ghczmprim_GHCziCString_unpackCStringzh_info
             U ghczmprim_GHCziClasses_DZCEq_static_info
             U ghczmprim_GHCziTuple_Z0T_closure
             U ghczmprim_GHCziTuple_Z2T_con_info
             U ghczmprim_GHCziTypes_Bool_closure_tbl
             U ghczmprim_GHCziTypes_False_closure
             U ghczmprim_GHCziTypes_Izh_con_info
             U ghczmprim_GHCziTypes_True_closure
             U newCAF
             U stg_CAF_BLACKHOLE_info
             U stg_MUT_ARR_PTRS_DIRTY_info
             U stg_MUT_VAR_CLEAN_info
             U stg_ap_0_fast
             U stg_atomicModifyMutVarzh
             U stg_bh_upd_frame_info
             U stg_gc_ut
             U stg_newAlignedPinnedByteArrayzh
             U stg_newByteArrayzh
             U stg_newMutVarzh
             U stg_upd_frame_info
             U val_compare_and_swap_word

Maybe there's some library or object that atomic-primops can explicitly depend on to make sure this stuff gets linked?

from haskell-lockfree.

Update: Simon Marlow said this is a GHC bug and that he'll fix it:

http://www.haskell.org/pipermail/ghc-devs/2013-July/001714.html

from haskell-lockfree.

By the way, I don't run into this bug on Mac. This is a Linux-specific bug it seems.

from haskell-lockfree.

This bug remains for 7.6 but it's fixed in 7.8 so I'm closing this now.

from haskell-lockfree.

I'm running into this bug with ghc-7.8.3 on linux. We're using ghc with the following

 ,("Dynamic by default","NO")
 ,("GHC Dynamic","NO")

but otherwise it's a standard build. I've hacked around it by enabling RtsDup for now, but I think it may be a remaining bug in ghc. Just wanted to point it out in case other users run into the same problem. Also I wonder if it works on Windows at all (which AFAIK is also not dynamic by default).

from haskell-lockfree.