3

This is a follow-up of this post (unfortunately).

I am trying to stack build a project where Main.hs has some FFI calls to a proprietary C library, libMyLib.so, located in /usr/local/lib (which is included in LD_LIBRARY_PATH).

When run in GHCi (outside stack) with the command ghci /usr/local/lib/ -lMyLib, everything works fine.

However when running stack build, I have a linking-related issue : 

me@user:~/myproject$ stack build

myproject-0.1.0.0: build
Preprocessing library myproject-0.1.0.0...
In-place registering myproject-0.1.0.0...
Preprocessing executable 'myproject-exe' for myproject-0.1.0.0...
Linking .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/myproject-exe/myproject-exe ...
/usr/bin/ld: .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/myproject-exe/myproject-exe-tmp/Main.o: undefined reference to symbol 'mycfunction'
/usr/local/lib/libMyLib.so.2: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status

--  While building package myproject-0.1.0.0 using:
      /home/me/.stack/setup-exe-cache/x86_64-linux/setup-Simple-Cabal-1.22.5.0-ghc-7.10.3 --builddir=.stack-work/dist/x86_64-linux/Cabal-1.22.5.0 build lib:myproject exe:myproject-exe --ghc-options " -ddump-hi -ddump-to-file"
    Process exited with code: ExitFailure 1

Here is an extra of the associated cabal file: 

library
  hs-source-dirs:      src
  exposed-modules:     Lib
  build-depends:       base >= 4.7 && < 5
  default-language:    Haskell2010
  extra-libraries:     MyLib

executable myproject-exe
  hs-source-dirs:      app
  main-is:             Main.hs
  ghc-options:         -threaded -rtsopts -with-rtsopts=-N
  build-depends:       base, bytestring, safe, split
                     , myproject
  default-language:    Haskell2010

Running stack exec env shows that the LD_LIBRARY_PATH points to the right directory (LD_LIBRARY_PATH=/usr/local/lib), and just to make sure I have added this directory to the .yaml file (extra-lib-dirs: [/usr/local/lib]).

I have played with various GCC compile options, e.g. -pthread instead of -threaded..., via the .cabal file parameters or directly via stack build (stack build --ghc-options="-foo..."), but to no avail.

My question: where else should I look? What kind of test should I run to find the origin of the issue (apparent linking problem)?

== EDIT ==
There were two versions of the same C library installed, and one has a dependency on another C library, say libOther.so. When I finally realized that, I added it to the cabal file and that worked fine : 

extra-libraries:     Other, MyLib
Community
  • 1
  • 1
Janthelme
  • 989
  • 10
  • 23
  • Can you increase verbosity of the build? LD_LIBRARY_PATH has nothing to do with linking and only adds confusion. I recommend using `-rpath` instead. Your linker command needs to get `-L /usr/local/lib` but this doesn't seem to happen. – n. m. could be an AI Jan 10 '16 at 10:06
  • A guess: `stack build --extra-lib-dirs=/usr/local/lib`. Does that work ? – Sibi Jan 10 '16 at 10:39
  • @n.m and Sibi thanks for your suggestions. I tried as recommended but without success. But I finally got to the bottom of it : I needed to add an extra library dependency, which I'll describe in an edit. – Janthelme Jan 10 '16 at 11:35
  • Hmm. "needed to add an extra library dependency" — that's what I thought initially and commented to that effect. Deleted the comment because something about it seemed wrong. – n. m. could be an AI Jan 10 '16 at 14:06
  • 3
    Why don't you answer the question yourself instead of the edit ? – Sibi Jan 10 '16 at 14:59
  • @JeanAnthelme you should post the solution you found as an answer and accept it so this question falls out of the "unanswered" queue. – sclv Mar 12 '16 at 01:54

0 Answers0