On 14 April 2015 at 08:52, Michael Snoyman
Actually, I seem to have found the problem:
open("/usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/x86_64-linux-gnu/gconv/gconv-modules", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
I found that I needed to copy over the following files to make my program complete:
/usr/lib/x86_64-linux-gnu/gconv/gconv-modules /usr/lib/x86_64-linux-gnu/gconv/UTF-32.so
Once I did that, I could get the executable to run in the chroot. However, even running the statically linked executable still required most of the shared libraries to be present inside the chroot. So it seems that:
* We can come up with a list of a few files that need to be present inside a Docker image to provide for minimal GHC-compiled executables * There's a bug in the RTS that results in an infinite loop
I'm going to try to put together a semi-robust solution for the first problem, and I'll report the RTS issue on Trac.
Excellent that you found the issue. Is there some way of controlling which libc ghc links with? There are quite a few alternatives out there, and maybe it'd be easier to create a *true* static binary by using another libc? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus