Wai template functions cannot find Libz.so

5
votes

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

This is the error I'm getting while trying to install some of the WAI libraries:

  • wai-app-static-3.1.6.2
  • wai-websockets-3.0.1.2

This seems to be related to Template Haskell having problems with dynamic linking. Other packages that link to zlib (or libz or z or libz1g or whatever the flavor of the month package manager has chosen to call the standard compression library) work fine, it is only the ones that are trying to link to it at dynamically at compile time.

I've used nix-env -i zlib && nix-shell -p zlib

I've done apt-get install on zlib1g, zlib1g-dev, lib32z1, zlib1g:i386, libc6-i386, lib32stdc++6, lib32gcc1, lib32ncurses5 (?!) as suggested by other zlib question.

whereis libz.so gives /usr/lib/x86_64-linux-gnu/libz.a /usr/lib/x86_64-linux-gnu/libz.so so I think the library is actually installed.

I got a stripped down version of wai-app-static working by stripping out all the TH code, but I cannot extract it from wai-websockets without breaking the whole package.

Has anyone found a way to get these libraries to install, preferably with Nix, but at this point however I can make it happen. I've been trying for three days to get a working build and have blown my entire weeks side project time without getting to write a single line of my own code. I'll take any hack that will work at this point.

Someone asked for the command line used. Here is is as generated by cabal:

/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
1
haskellzlibyesodtemplate-haskellhaskell-wai
:s/revieved/received/ – John F. Miller
This turns out to be a NIX issue. It's version of gcc does not provide the ghci with the correct path to libraries. At the command line this can be fixed with -L/usr/lib/ but there is no way (that I have found) to thread this all the way through to the Template Haskell invocation. I'm starting from scratch without NIX which seems to me to have created far more problems than it solved. – John F. Miller

1 Answers

1
votes

I feel your pain.
You've probably already tried these, but here are some random ideas:

  • Make sure the symlink /usr/lib/x86_64-linux-gnu/libz.so still has a valid target.
  • Add "-L /usr/lib/x86_64-linux-gnu" to the command line.
  • Try using -rpath in the linker command line (ftp://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_node/ld_3.html) although it probably won't help.
  • Make sure that the compiler architecture is really x86_64-linux-gnu (gcc -print-multiarch).

If I think of any more, I'll be back. :-)

It might (or might not) help if you could post the verbatim gcc command line.