You may need to resort to strace to find out what's trying to pull in libgmp.so.whatever.
I don't know how to do that. And anyway, I don't have access to the machine on which the customer is reporting this. I do believe the report - there is no compilation going on here, they are only running our GHC-compiled binary. They know nothing about GHC (not even that we are using it). I was hoping that there would be some general knowledge about this so I could just pass it on to our customers. But I see everyone else is as surprised as I am about a supposedly static GHC-compiled binary requiring a libgmp.so to run.
Unless this program is like xmonad and requires ghc behind the scenes to build something, in which case you would indeed need everything that ghc requires (and, of course, ghc itself).
No definitely not. Erik de Castro Lopo wrote:
I suspect the OP's exectuable is already being compiled static.
I compiled it static. Brandon Allbery wrote:
Yes; which leaves the question of why it requires libgmp.so, and if it's static the only things I can think of are (a) it's using dlopen(), or (b) it's running something else that is not static and requires libgmp.so.
Right. Could a dependent library be causing this? For example, this program depends on direct-sqlite, which in turn links to sqlite via FFI. It also depends on wai, which pulls in quite a few indirect dependencies. If so - how would I investigate this and get a complete list of the system libraries that customers are required to install as prerequisites? Jens Petersen wrote:
You built ghc yourself?
No. It is the generic Linux binary tarball from GHC HQ.
And ran ldd on $bindir/ghc or $libdir/ghc-version ?
No, in $bindir that's just a shell script. It's in $libdir. The executable is ghc; ghc-version is a directory containing object files compiled from libraries. Thanks, Yitz