Стек Haskell и библиотеки C II

Это продолжение этого сообщения (к сожалению).

Я пытаюсь stack build создать проект, в котором Main.hs есть несколько вызовов FFI к проприетарной библиотеке C, libMyLib.so, расположенной в /usr/local/lib (которая включена в LD_LIBRARY_PATH).

При запуске в GHCi (вне stack) командой ghci /usr/local/lib/ -lMyLib все работает нормально.

Однако при запуске stack build у меня возникает проблема, связанная со связью:

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

Вот дополнительный связанный файл клики:

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

Запуск stack exec env показывает, что LD_LIBRARY_PATH указывает на правильный каталог (LD_LIBRARY_PATH=/usr/local/lib), и просто чтобы убедиться, что я добавил этот каталог в файл .yaml (extra-lib-dirs: [/usr/local/lib]).

Я играл с различными вариантами компиляции GCC, например. -pthread вместо -threaded..., через параметры файла .cabal или напрямую через stack build (stack build --ghc-options="-foo..."), но безрезультатно.

Мой вопрос: где еще мне искать? Какой тип теста я должен выполнить, чтобы найти источник проблемы (очевидная проблема со связыванием)?

== РЕДАКТИРОВАТЬ ==
Были установлены две версии одной и той же библиотеки C, и одна из них имеет зависимость от другой библиотеки C, скажем, libOther.so. Когда я, наконец, понял это, я добавил его в файл клики, и это сработало нормально:

extra-libraries:     Other, MyLib

person Janthelme    schedule 10.01.2016    source источник
comment
Можете ли вы увеличить детализацию сборки? LD_LIBRARY_PATH не имеет ничего общего со связыванием и только добавляет путаницы. Вместо этого я рекомендую использовать -rpath. Ваша команда компоновщика должна получить -L /usr/local/lib, но, похоже, этого не происходит.   -  person n. 1.8e9-where's-my-share m.    schedule 10.01.2016
comment
Предположение: stack build --extra-lib-dirs=/usr/local/lib. Это работает ?   -  person Sibi    schedule 10.01.2016
comment
@n.m и Сиби спасибо за ваши предложения. Я пробовал, как рекомендовали, но безуспешно. Но я, наконец, добрался до сути: мне нужно было добавить дополнительную зависимость от библиотеки, которую я опишу в редактировании.   -  person Janthelme    schedule 10.01.2016
comment
Хм. необходимо добавить дополнительную зависимость от библиотеки — так я думал изначально и прокомментировал это. Удалил комментарий, потому что что-то в нем было не так.   -  person n. 1.8e9-where's-my-share m.    schedule 10.01.2016
comment
Почему бы вам не ответить на вопрос самостоятельно вместо редактирования?   -  person Sibi    schedule 10.01.2016
comment
@JeanAnthelme, вы должны опубликовать найденное решение в качестве ответа и принять его, чтобы этот вопрос выпал из очереди без ответа.   -  person sclv    schedule 12.03.2016