This is expected behavior, you'll need to pass in appropriate flags to
Stack to tell it to do static compilation. There are some Github issues
discussing this already on the Stack tracker.

On Tue, Nov 3, 2015 at 11:21 PM, surdus [email protected] wrote:

When I try to run compiled executable in docker container I receive such
error:

docker run -it bf05fe86682d test-exe
test-exe: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory

I use stack as build system. For test created empty stack project using
command stack new test
My image configuration in stack.yaml:

image:
container:
base: "fpco/haskell-scratch:integer-gmp"

—
Reply to this email directly or view it on GitHub
#7.

Thanks for reply.
As I understand this one you are talking about. Yes, if add -static -optl-static flags to my cabal file it would help in this case. But I am not sure if this is a right way. What about library dependencies that can't be linked statically (license restrictions or closed-source dependencies without libraries for static linking)?
Also if link all static, so it is enough to use docker scratch image as a base to run such executable.
Maybe it has reason to add libgcc_s.so.1 into the image. But I am not sure if this is a common issue.

The general answer I'd give is: when doing something non-standard, you should modify the haskell-scratch image. My goal with this image is to make it as minimalistic as possible as an example of what can be done. Many people will require tweaks to the image to get real-world projects to run with it. But if we made all of those tweaks in this base image, it would no longer be a "scratch" image.

Scope of project clarified in 032e00b.