Функции шаблона Wai не могут найти Libz.so

<command line>: can't load .so/.DLL for: libz.so (libz.so: cannot open shared object file: no such file or directory)

Это ошибка, которую я получаю при попытке установить некоторые библиотеки WAI:

  • вай-приложение-статический-3.1.6.2
  • вай-вебсокеты-3.0.1.2

Похоже, это связано с тем, что Template Haskell имеет проблемы с динамической компоновкой. Другие пакеты, которые ссылаются на zlib (или libz, или z, или libz1g, или что-то другое, выбранное диспетчером пакетов месяца для вызова стандартной библиотеки сжатия), работают нормально, это только те, которые пытаются динамически ссылаться на него при компиляции. время.

Я использовал nix-env -i zlib && nix-shell -p zlib

Я сделал apt-get install на zlib1g, zlib1g-dev, lib32z1, zlib1g:i386, libc6-i386, lib32stdc++6, lib32gcc1, lib32ncurses5 (?!), как было предложено другим вопросом zlib.

whereis libz.so дает /usr/lib/x86_64-linux-gnu/libz.a /usr/lib/x86_64-linux-gnu/libz.so, поэтому я думаю, что библиотека действительно установлена.

Я получил урезанную версию работы wai-app-static, удалив весь код TH, но я не могу извлечь его из wai-websockets, не сломав весь пакет.

Кто-нибудь нашел способ установить эти библиотеки, желательно с помощью Nix, но на данный момент я могу это сделать. Я пытался в течение трех дней получить работающую сборку и потратил все свое время на сторонние проекты недели, так и не написав ни одной строки собственного кода. Я возьму любой хак, который будет работать на данный момент.


Кто-то спросил используемую командную строку. Вот как генерируется клика:

/home/jfmiller28/.nix-profile/bin/ghc --make -fbuilding-cabal-package -O -static -dynamic-too -dynosuf dyn_o -dynhisuf dyn_hi -outputdir dist/build -odir dist/build -hidir dist/build -stubdir dist/build -i -idist/build -i. -idist/build/autogen -idist/build/global-autogen -Idist/build/autogen -Idist/build/global-autogen -Idist/build -optP-include -optPdist/build/autogen/cabal_macros.h -this-unit-id wai-app-static-3.1.6.2-LkSB3kK5rpLKV2jrN2AtNR -hide-all-packages -Wmissing-home-modules -package-db dist/package.conf.inplace -package-id base-4.10.0.0 -package-id wai-3.2.1.2-i068T7XVUlLxs3fKcREfc -package-id bytestring-0.10.8.2 -package-id http-types-0.12.1-2xWgExX0qOl7yKh7LxUBE2 -package-id transformers-0.5.2.0 -package-id unix-compat-0.5.1-1iiashTJMVo4Z2Bo2H1Lus -package-id directory-1.3.0.2 -package-id containers-0.5.10.2 -package-id time-1.8.0.2 -package-id old-locale-1.0.0.7-7dfSJrRIye3EgzsPnyvNPA -package-id file-embed-0.0.11-8MbWlMh1peh6Y3L9VmTvZW -package-id text-1.2.3.0-1kNDH38DjPO1AsUcP35BNj -package-id cryptonite-0.25-GXzdjgRkEVOKY7fpyz8xaf -package-id memory-0.14.16-5MukHHE9BjI5qglqVrRBGo -package-id http-date-0.0.8-CG5y9eYkeUn6wOfbHom4pU -package-id blaze-html-0.9.1.1-CsJ11WXjlLxBrTMbayeoQA -package-id blaze-markup-0.8.2.1-I4KSuVAN6lL9BOh5kJrkji -package-id mime-types-0.1.0.8-2EwGkNBk8W7Io9sTyOvZ5e -package-id unordered-containers-0.2.9.0-EAgi4LFNl39D8BgT0rhlvy -package-id template-haskell-2.12.0.0 -package-id zlib-0.6.2-KD4SSz9PUL57YfOUBW0y3t -package-id filepath-1.4.1.2 -package-id wai-extra-3.0.24.2-18RlcgWRZiDEaepZgYOTPU -package-id optparse-applicative-0.12.1.0-9EJm9hUjsSHG4weMNInJgv -package-id warp-3.2.23-590EqUmbUTP1AQ3mjwuKbZ -XHaskell98 -XCPP Network.Wai.Application.Static WaiAppStatic.Storage.Filesystem WaiAppStatic.Storage.Embedded WaiAppStatic.Listing WaiAppStatic.Types WaiAppStatic.CmdLine Util WaiAppStatic.Storage.Embedded.Runtime WaiAppStatic.Storage.Embedded.TH -Wall

person John F. Miller    schedule 27.08.2018    source источник
comment
:s/просмотрено/получено/   -  person John F. Miller    schedule 02.09.2018
comment
Оказывается, это проблема NIX. Эта версия gcc не предоставляет ghci правильный путь к библиотекам. В командной строке это можно исправить с помощью -L/usr/lib/, но нет никакого способа (который я нашел) пропустить это до вызова шаблона Haskell. Я начинаю с нуля без NIX, который, как мне кажется, создал гораздо больше проблем, чем решил.   -  person John F. Miller    schedule 08.09.2018


Ответы (1)


Я чувствую вашу боль.
Вероятно, вы уже пробовали это, но вот несколько случайных идей:

  • Убедитесь, что символическая ссылка /usr/lib/x86_64-linux-gnu/libz.so все еще имеет действительную цель.
  • Добавьте «-L /usr/lib/x86_64-linux-gnu» в командную строку.
  • Попробуйте использовать -rpath в командной строке компоновщика (ftp://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_node/ld_3.html), хотя, вероятно, это не поможет.
  • Убедитесь, что архитектура компилятора действительно x86_64-linux-gnu (gcc -print-multiarch).

Если я еще что-нибудь придумаю, я вернусь. :-)

Может (а может и нет) помочь, если вы опубликуете дословную командную строку gcc.

person binky    schedule 05.09.2018
comment
И просто для удовольствия, попробуйте добавить символическую ссылку в /usr/lib (т.е. ln -s /usr/lib/x86_64-linux-gnu/libz.so /usr/lib/libz.so) - person binky; 07.09.2018
comment
Ну, поскольку мы говорим о GHC (и с шаблоном Haskell GHCi) как о запуске через клику, я не могу опубликовать командную строку gcc. Я попытаюсь извлечь команду компоновщика из Кабала, но не обещаю. Я добавил ссылку, которую вы предложили в комментарии. Ожидание процесса сборки.... - person John F. Miller; 08.09.2018