Skip to content

Add GCC runtime (libgcc_s.so). #10

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Add GCC runtime (libgcc_s.so). #10

wants to merge 1 commit into from

Conversation

proger
Copy link

@proger proger commented Dec 31, 2015

Since the scratch image already contains glibc stuff
(because it's impossible to use -optl-static binaries truly
statically linked if GHC runtime uses glibc), it also makes
sense to add the GCC runtime.

It makes the image usable as a base for binaries with dynamically-linked GHC runtimes
at a price of 88 kilobytes.

Also closes #7.

Since the scratch image already contains glibc stuff
(because it's impossible to use -optl-static binaries truly
 statically linked if GHC runtime uses glibc), it also makes
sense to add the GCC runtime.

It makes the image usable as a base for binaries with dynamically-linked GHC runtimes
at a price of 88 kilobytes.
@snoyberg
Copy link
Member

snoyberg commented Jan 4, 2016

See this comment for my reservations about this PR: #7 (comment)

@proger
Copy link
Author

proger commented Jan 4, 2016

It is weird that haskell-scratch is meant to be used for statically binaries — there is an image for that, scratch.

Neither the README, nor the blog post, nor the example Makefile say anything about GHC/Glibc idiosyncrasies wrt static linking (the fact that -optl-static is being used and actually still depends on the use of the dynamic linker and most dynamic libraries, while and libgmp is included for LGPL compliance) — while adding the GCC runtime makes every Haskell dynamically-linked binary without any native dependencies work.

So, given the README says

Base Docker image which includes minimal shared libraries for GHC-compiled executables

I'm merely fixing a bug.

/mnt/haskell-scratch/example# make run
Sending build context to Docker daemon 842.8 kB
Step 0 : FROM fpco/haskell-scratch:integer-gmp
 ---> cc6e8498340d
Step 1 : ADD hello /usr/bin/hello
 ---> Using cache
 ---> 33bcedc11409
Step 2 : CMD hello
 ---> Using cache
 ---> 0c820f48c704
Successfully built 0c820f48c704
hello: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory
Makefile:11: recipe for target 'run' failed

If you'd like I can squeeze proper README updates in this PR.

@snoyberg
Copy link
Member

snoyberg commented Jan 4, 2016

The assumption that the scratch image is sufficient for GHC-compiled static executables is not true. At the very least, libgmp needs to be present. Other libraries - like iconv and its resources - need to be present as well. That's what this image is designed to solve. I've already updated the README to clarify that this is for statically compiled executables. The reason this was never called out before is because static compilation is the default for GHC.

@proger
Copy link
Author

proger commented Jan 4, 2016

The reason this was never called out before is because static compilation is the default for GHC.

You probably mean static linking of haskell stuff, not "native" stuff.

The problem is still there and the gcc runtime must be present:

root@1b9d2d881d57:/mnt/haskell-scratch/example# make hello SHELL="bash -x"
+ ghc hello.hs
Linking hello ...
+ strip hello
root@1b9d2d881d57:/mnt/haskell-scratch/example# ldd ./hello
    linux-vdso.so.1 =>  (0x00007ffebe7ae000)
    libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f874f224000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f874ef1e000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f874ed16000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f874eb12000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f874e8fc000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f874e537000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f874e319000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f874f498000)
root@1b9d2d881d57:/mnt/haskell-scratch/example# ldd ./hello | grep gcc_s
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f2a63348000)

@snoyberg
Copy link
Member

snoyberg commented Jan 4, 2016

Can you provide the full reproducing case you're using? It's very hard to guess at what's going on here, especially since my tests with the current image have worked for minimalistic examples.

@proger
Copy link
Author

proger commented Jan 4, 2016

I simply try to use the provided example and GHC from fpco/stack-build:lts-3.18 (6eaa0c6bcea6). fpco/haskell-scratch:integer-gmp is cc6e8498340d.

@snoyberg
Copy link
Member

snoyberg commented Jan 4, 2016

I'm not sure what's going on there. Pinging @dysinger who wrote that example to comment. Also pinging @ketzacoatl who may have experimented with it recently.

@proger
Copy link
Author

proger commented Mar 21, 2016

Bumping the thread. I think this matter is still worth pursuing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

error while loading shared libraries: libgcc_s.so.1
2 participants