Combining lvish with Template Haskell: undefined symbol: nand_and_fetch_8

[robstewart57]

Hi,

I'm experiencing a compilation error undefined symbol: nand_and_fetch_8 stemming from bits-atomic, when combining Template Haskell with lvish 2.0.2.

I've put together a small test case.

Foo.hs

{-# LANGUAGE TemplateHaskell #-}

module Foo where
import Language.Haskell.TH

build_p1 :: Q [Dec]
build_p1 = return
    [ FunD p1
             [ Clause [TupP [VarP a,VarP b]] (NormalB (VarE a)) []
             ]
    ] where
       p1 = mkName "p1"
       a = mkName "a"
       b = mkName "b"

And Main.hs

{-# LANGUAGE TemplateHaskell #-}

module Main where
import Foo
import Control.LVish (Par) -- would require the lvish library

$(build_p1)
main = print $ p1 (1,2)

For convenience, this code has been cabalised, available here: http://www.macs.hw.ac.uk/~rs46/files/lvish-template-haskell-fail-case.tar.gz . When trying to compile with cabal install, I get:

<command line>: can't load .so/.DLL for: /home/rob/.cabal/lib/i386-linux-ghc-7.10.1/bitsa_EfESR243Us2C1YfvGtoj49/libHSbits-atomic-0.1.3-EfESR243Us2C1YfvGtoj49-ghc7.10.1.so (/home/rob/.cabal/lib/i386-linux-ghc-7.10.1/bitsa_EfESR243Us2C1YfvGtoj49/libHSbits-atomic-0.1.3-EfESR243Us2C1YfvGtoj49-ghc7.10.1.so: undefined symbol: nand_and_fetch_8)

This symbol should be found from cbits/atomic-bitops-gcc.h and cbits/atomic-bitops-gcc.c from the bits-atomic package, but it's not being found. I don't get this error if I comment out the lvish build-depends entry in the cabal file and comment out the import of Control.LVish in Main.hs .

My software environment is: GHC 7.10, 32bit OS, bits-atomic-0.1.3, lvish-2.0.2. Questions:

1. Is the lvish and template haskell combination above supposed to work?
2. Can someone else reproduce my compilation error, based on the cabal project I link to above?

[osa1]

Sorry for late response,

1. Yes, there's no reason why they wouldn't work together.
2. I couldn't reproduce it. I'm trying with GHC 7.10.1 and Cabal 1.22.4.0, on 64bit Linux. I found this relevant answer: http://stackoverflow.com/questions/130740/link-error-when-compiling-gcc-atomic-operation-in-32-bit-mode .

What happens when you try to compile this program with GCC?

int main()
{
    int i = 3;
    int j = __sync_nand_and_fetch(&i, 1);
    return 0;
}

[robstewart57]

Thanks @osa1 . I've boiled it down to a small test case.

Main.hs

module Main where

import Data.Bits.Atomic
import Data.Word
import Foreign.Ptr

main = do
  x <- nandAndFetch nullPtr 1 :: IO Word8
  print x

Setup.hs

import Distribution.Simple
main = defaultMain

cas-test.cabal

name:                cas-test
version:             0.1.0.0
license-file:        LICENSE
author:              Rob Stewart
maintainer:          robstewart57@gmail.com
category:            Testing
build-type:          Simple
cabal-version:       >=1.10

executable cas-test
  main-is:             Main.hs
  build-depends:       base >=4.8 && <4.9 , bits-atomic
  default-language:    Haskell2010

Trying to compile Main.hs with cabal in isolation gives the error I originally reported:

$ cabal install
Resolving dependencies...
Configuring cas-test-0.1.0.0...
Building cas-test-0.1.0.0...
Failed to install cas-test-0.1.0.0
Build log ( /home/rob/.cabal/logs/cas-test-0.1.0.0.log ):
Configuring cas-test-0.1.0.0...
Building cas-test-0.1.0.0...
Preprocessing executable 'cas-test' for cas-test-0.1.0.0...
Linking dist/build/cas-test/cas-test ...
dist/build/cas-test/cas-test-tmp/Main.o: In function `c3wx_info':
(.text+0xaa): undefined reference to `nand_and_fetch_8'
collect2: error: ld returned 1 exit status
cabal: Error: some packages failed to install:
cas-test-0.1.0.0 failed during the building phase. The exception was:
ExitFailure 1

The key message is:

(.text+0xaa): undefined reference to `nand_and_fetch_8'

For some reason, the symbols from cbits/atomic-bitops-gcc.c and cbits/atomic-bitops-gcc.h from the bits-atomic library are not being found.

[rrnewton]

This was on Linux, right? Is clang being used here instead of gcc? Which distro, etc?

I saw similar problems with bits-atomic on recent versions of Mac OS.. Our plan in #127 is to just split our package to wean the main LVish package off of bits-atomic.

Bits-atomic seems like it's probably abandonware, so we may need to fork/maintain it or use something else. @DreamLinuxer is going to contact the maintainer.