<div dir="ltr">Trac ticket created: <a href="https://ghc.haskell.org/trac/ghc/ticket/10298#ticket">https://ghc.haskell.org/trac/ghc/ticket/10298#ticket</a><div><br></div><div>I've also put together a Docker image called snoyberg/haskell-scratch (source at <a href="https://github.com/snoyberg/haskell-scratch">https://github.com/snoyberg/haskell-scratch</a>), which seems to be working for me. Here's a minimal test I've put together which seems to be succeeding (note that I've also tried some real life programs):</div><div><br></div><div><pre class="special_formatting" style="padding:0.5rem;font-family:Monaco,Menlo,Consolas,'Courier New',monospace;font-size:0.75rem;color:rgb(51,51,51);border-radius:4px;margin-top:0.5rem;margin-bottom:0.2rem;line-height:1.15rem;word-break:normal;word-wrap:break-word;white-space:pre-wrap;border:1px solid rgba(0,0,0,0.14902);background:rgb(251,250,248)">#!/bin/bash<br style><br style>set -e<br style>set -x<br style><br style>cat > tiny.hs <<EOF<br style>main :: IO ()<br style>main = putStrLn "Hello from a tiny Docker image"<br style>EOF<br style><br style>ghc tiny.hs<br style>strip tiny<br style><br style>cat > Dockerfile <<EOF<br style>FROM <span class="mention" style="background:rgb(255,243,184)">snoyberg</span>/haskell-scratch<br style>ADD tiny /tiny<br style>CMD ["/tiny"]<br style>EOF<br style><br style>docker build -t tiny .<br style>docker run --rm tiny</pre><div><br><div class="gmail_quote">On Tue, Apr 14, 2015 at 9:52 AM Michael Snoyman <<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Actually, I seem to have found the problem:<br><br>open("/usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache", O_RDONLY) = -1 ENOENT (No such file or directory)
<br>open("/usr/lib/x86_64-linux-gnu/gconv/gconv-modules", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
<br><br>I found that I needed to copy over the following files to make my program complete:<div><br></div><div>/usr/lib/x86_64-linux-gnu/gconv/gconv-modules<br>/usr/lib/x86_64-linux-gnu/gconv/UTF-32.so</div><div><br></div><div>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:</div><div><br></div><div>* 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</div><div>* There's a bug in the RTS that results in an infinite loop</div><div><br></div><div>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.</div></div><div dir="ltr"><div><br><div class="gmail_quote">On Tue, Apr 14, 2015 at 9:25 AM Michael Snoyman <<a href="mailto:michael@snoyman.com" target="_blank">michael@snoyman.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I have a bit more information about this. In particular: I'm able to reproduce this using chroot (no Docker required), and it's reproducing with a dynamically linked executable too. Steps I used to reproduce:<br><div><br></div><div>1. Write a minimal "foo.hs" containing `main = putStrLn "Hello World"`</div><div>2. Compile that executable and put it in an empty directory</div><div>3. Run `ldd` on it and copy all necessary libraries inside that directory</div><div>4. Run `sudo strace -o log.txt . /foo`</div><div><br></div><div>I've uploaded the logs to:</div><div><br></div><div><a href="https://gist.github.com/snoyberg/095efb17e36acc1d6360" target="_blank">https://gist.github.com/snoyberg/095efb17e36acc1d6360</a><br></div><div><br></div><div>Note that, due to size of the output, I killed the process just a few seconds after starting it, but when I let the output run much longer, I didn't see any difference in the results. I'll continue poking at this a bit, but most likely I'll open a GHC Trac ticket about it later today.</div></div><br><div class="gmail_quote">On Tue, Apr 14, 2015 at 12:39 AM Albert Y. C. Lai <<a href="mailto:trebla@vex.net" target="_blank">trebla@vex.net</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I wonder whether you already know the following, and whether it is<br>
relevant to begin with. (Plus, my knowledge is fairly sketchy.)<br>
<br>
Even though you statically link glibc, its code will, at run time,<br>
dlopen a certain part of glibc.<br>
<br>
Why: To provide a really uniform abstraction layer over user account<br>
queries, e.g., man 3 getpwnam, regardless of whether the accounts are<br>
from /etc/passwd, LDAP, or whatever.<br>
<br>
Therefore, during run time, glibc first reads some config files of the<br>
host to see what kind of user account database the host uses. If it's<br>
/etc/passwd, then dlopen the implementation of getpwnam and friends for<br>
/etc/passwd; else, if it's LDAP, then dlopen the implementation of<br>
getpwnam and friends for LDAP; etc etc.<br>
<br>
So that later when you call getpwnam, it will happen to "do the right<br>
thing".<br>
<br>
This demands the required *.so files to be accessible during run time.<br>
Moreoever, if you statically link glibc, this also demands the required<br>
*.so files to version-match the glibc you statically link.<br>
<br>
(It is the main reason why most people give up on statically linking glibc.)<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
</blockquote></div></blockquote></div></div></div></blockquote></div></div></div></div>