<div dir="ltr"><p dir="ltr">The /lib/ version of the file was necessary for statically linked executables I believe. It's arguably better to just remove it and tell people "don't do static executables" I suppose, given that they're clearly not *actually* static in reality ;)</p>
<br><div class="gmail_quote">On Sat, Apr 18, 2015, 12:51 PM Vo Minh Thu <<a href="mailto:noteed@gmail.com" target="_blank">noteed@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Michael, thanks for solving this !<br>
<br>
I wonder how you came up with the need for /lib/ld-linux-x86-64.so.2.<br>
I have needed only /lib64/ld-linux-x86-64.so.2 (which you have too),<br>
so maybe you added it by mistake.<br>
<br>
B.t.w, if you don't want to use a Dockerfile, you can do this:<br>
<br>
    > tar -C rootfs -c . | docker import - tiny<br>
<br>
where rootfs is your repository.<br>
<br>
2015-04-14 10:43 GMT+02:00 Michael Snoyman <<a href="mailto:michael@snoyman.com" target="_blank">michael@snoyman.com</a>>:<br>
> Trac ticket created: <a href="https://ghc.haskell.org/trac/ghc/ticket/10298#ticket" target="_blank">https://ghc.haskell.org/trac/ghc/ticket/10298#ticket</a><br>
><br>
> I've also put together a Docker image called snoyberg/haskell-scratch<br>
> (source at <a href="https://github.com/snoyberg/haskell-scratch" target="_blank">https://github.com/snoyberg/haskell-scratch</a>), which seems to be<br>
> working for me. Here's a minimal test I've put together which seems to be<br>
> succeeding (note that I've also tried some real life programs):<br>
><br>
> #!/bin/bash<br>
><br>
> set -e<br>
> set -x<br>
><br>
> cat > tiny.hs <<EOF<br>
> main :: IO ()<br>
> main = putStrLn "Hello from a tiny Docker image"<br>
> EOF<br>
><br>
> ghc tiny.hs<br>
> strip tiny<br>
><br>
> cat > Dockerfile <<EOF<br>
> FROM snoyberg/haskell-scratch<br>
> ADD tiny /tiny<br>
> CMD ["/tiny"]<br>
> EOF<br>
><br>
> docker build -t tiny .<br>
> docker run --rm tiny<br>
><br>
><br>
> On Tue, Apr 14, 2015 at 9:52 AM Michael Snoyman <<a href="mailto:michael@snoyman.com" target="_blank">michael@snoyman.com</a>> wrote:<br>
>><br>
>> Actually, I seem to have found the problem:<br>
>><br>
>> open("/usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache", O_RDONLY) = -1<br>
>> ENOENT (No such file or directory)<br>
>> open("/usr/lib/x86_64-linux-gnu/gconv/gconv-modules", O_RDONLY|O_CLOEXEC)<br>
>> = -1 ENOENT (No such file or directory)<br>
>><br>
>> I found that I needed to copy over the following files to make my program<br>
>> complete:<br>
>><br>
>> /usr/lib/x86_64-linux-gnu/gconv/gconv-modules<br>
>> /usr/lib/x86_64-linux-gnu/gconv/UTF-32.so<br>
>><br>
>> Once I did that, I could get the executable to run in the chroot. However,<br>
>> even running the statically linked executable still required most of the<br>
>> shared libraries to be present inside the chroot. So it seems that:<br>
>><br>
>> * We can come up with a list of a few files that need to be present inside<br>
>> a Docker image to provide for minimal GHC-compiled executables<br>
>> * There's a bug in the RTS that results in an infinite loop<br>
>><br>
>> I'm going to try to put together a semi-robust solution for the first<br>
>> problem, and I'll report the RTS issue on Trac.<br>
>><br>
>> On Tue, Apr 14, 2015 at 9:25 AM Michael Snoyman <<a href="mailto:michael@snoyman.com" target="_blank">michael@snoyman.com</a>><br>
>> wrote:<br>
>>><br>
>>> I have a bit more information about this. In particular: I'm able to<br>
>>> reproduce this using chroot (no Docker required), and it's reproducing with<br>
>>> a dynamically linked executable too. Steps I used to reproduce:<br>
>>><br>
>>> 1. Write a minimal "foo.hs" containing `main = putStrLn "Hello World"`<br>
>>> 2. Compile that executable and put it in an empty directory<br>
>>> 3. Run `ldd` on it and copy all necessary libraries inside that directory<br>
>>> 4. Run `sudo strace -o log.txt . /foo`<br>
>>><br>
>>> I've uploaded the logs to:<br>
>>><br>
>>> <a href="https://gist.github.com/snoyberg/095efb17e36acc1d6360" target="_blank">https://gist.github.com/snoyberg/095efb17e36acc1d6360</a><br>
>>><br>
>>> Note that, due to size of the output, I killed the process just a few<br>
>>> seconds after starting it, but when I let the output run much longer, I<br>
>>> didn't see any difference in the results. I'll continue poking at this a<br>
>>> bit, but most likely I'll open a GHC Trac ticket about it later today.<br>
>>><br>
>>> 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>
>>>><br>
>>>> 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<br>
>>>> 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>
><br>
><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>
><br>
</blockquote></div></div>