2016-05-05 17 views
3

Ich habe eine C++ - Bibliothek, die mit einer Haskell-Bibliothek gebündelt ist (und von dieser aufgerufen wird). Ich verwende einen benutzerdefinierten Build mit cabal, Makefile und Setup.hs Dateien fast identisch mit denen beschriebenen here. Ich möchte auch GHCi verwenden, so dass meine Makefile eine dynamische Bibliothek (.so) zusätzlich zur statischen (.a) Bibliothek erstellt.Stapel ghci mit Bibliothek

Hinweis: Ich denke, GHCi muss dynamische Bibliotheken verwenden; Wenn ich falsch liege, dann gibt es vielleicht eine einfachere Lösung.

Ich kann GHCi in dieser Umgebung arbeiten, indem Sie einen expliziten Pfad zur .so-Datei übergeben. In diesem Beitrag geht es darum, wie man stack ghci arbeiten kann. Der Hauptfehler, der dies erzeugt, ist cannot find libfoo.so (aufgrund des Hinzufügens extra-libraries: foo in der Cabal-Datei). Die Verwendung von -v zeigt, dass der Stack nicht in den "extra-lib-dirs" Pfaden sucht, die ich im Setup.hs-Skript geändert habe (bug). stack ghcisucht nach Bibliotheken in den "extra-lib-dirs", die in der Cabal-Datei angegeben sind. Leider kann ich aufgrund eines cabal bug keinen relativen Pfad für extra-lib-dirs angeben: es verursacht beide cabal configure und stack build mit dem gleichen Fehler fehlschlagen.

Ich möchte nicht meine C++ - Bibliothek systemweit installieren (was das Problem lösen würde, indem ich einen absoluten Pfad in extra-lib-dirs verwenden könnte).

Konkrete Fragen:

  1. Brauche ich eine .so Datei GHCi zu benutzen?
  2. Wie kann ich feststellen, stack ghci wo nach einer Bibliothek in einem relativ Pfad suchen?
+0

Können Sie LD_LIBRARY_PATH setzen, um das Problem zu lösen? – ErikR

+0

@ErikR Klingt vernünftig, aber anscheinend nicht. Wenn ich LD_LIBRARY_PATH einstelle, sucht 'stack ghci' dort nicht nach Bibliotheken. – crockeea

Antwort

0

This answer zeigt einen sauberere Weg, um eine C++ Bibliothek mit einer Haskell-Bibliothek enthält, die nicht die Verwendung von extra-libraries oder relativen Pfaden benötigt. Die Idee dahinter ist, dass die Kabalen das ganze schwere Heben durchführen, anstatt einen benutzerdefinierten Build-Typ zu verwenden.

stack ghci funktioniert (mit einigen Vorbehalten in Build-Reihenfolge aufgrund einer GHC bug).