-
Notifications
You must be signed in to change notification settings - Fork 132
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
Docker alpine wont compile the project #424
Comments
Thank you for opening this. Your work is very much appreciated, and I too hope to learn from this issue. My first thought is that this is a Wasmer issue, not a Gossamer issue. They explicitly state on their readme that Additionally, Gossamer still has a number of challenges to overcome before we can begin to be feature complete, let alone worry about things like cross-compatibility. My hesitation to merge your I think this boils down to one question -- Do you think these problems are isolated to Windows? If yes, I think this is jumping the gun on compatibility. |
I see, well in that case the best way to deal with this would be to add Appveyor to our build process, so we can at least have this step as part of Gossamer build steps and will remember us about it.
If we make the windows and macos builds part of the CI, there is no need to have someone to maintain it, as it should just work out of the box, and when it breaks we can at least know when and what change broke it, making it way easier.
Well, clearly the readme statement that works on Linux either incomplete (because its clearly not working on alpine) or they just dont know about it, or we are doing something wrong. So I would say that there is more benefits to use go to build go, than to rely on specifics of each operational system or the magic of
Good idea, I will look into it. |
You can add gcc with apk and some other libs. I tried to go into this rabbit hole last weekend but eventually gave up :D Last issue I remember was that when using Tried to use external linking when compiling as well, but same issue, for some reason can't get wasmer inside.. It would be nice to figure this out to create some smaller images :) |
The problem is that you are trying to use libwasmer_runtime_c_api.so that is compiled for glibc on a musl ( Alpine ) system. |
Hello, is there any README detailing the solution from @diegobes ? Is there any progress on that ticket ? Thank you ! |
Issue is tracked upstream under wasmerio/wasmer-go#113 |
Hi there 👋 Maybe a bit irrelevant, I made #1813 initially trying to address this issue, using sgerrand/alpine-pkg-glibc. The build would not work (logs below), but with a multi stage Dockerfile, it seems like it's feasible to run the program on a final image based on Alpine with that glibc package (correct me if I'm wrong!). The final image is 'only' 122MB, coming from the 3GB it is currently so that's nice. Regarding building on Alpine, Failed Alpine + glibc build logs:
Trying to build an example from the wasmer-go repo gives errors on Alpine + glibc:
|
I have been trying to make the current codebase to compile on docker alpine without success.
Expected Behavior
Project compilation with Go 1.13 should work cross platform.
Current Behavior
Current build fails, I believe is due to the package management being used go.mod not able to properly setup all required libs. As a side note, the usual way go projects are compiled (except for glide and go.mod) are to have a vendor folder with all the required libs and this is the most reliable way to use go.
Possible Solution
Update docker build to use Ubuntu, as it seems like it works fine in this distro.
Ditch go.mod and replace it with standard vendor folder managed by dep or something else.
Fix somehow the build and find out what is wrong / how to fix it.
Steps to Reproduce (for bugs)
There is already a PR with a solution for the bug, but I would like to understand why the current build is failing, maybe I am missing something. Please share your inputs.
The following list is what I tried to make it run, I have tried to compile with alpine (7,8,9,10) and using gcc(6,7,8) without success. I tried using standard go install ./... and I also built a small go class to build go within Go in order to be able to be sure that is not the go install magic (./...) doing something wrong and messing up things secretly.
So far I could not see much differences between using go install and the custom ci.go.
You can test it and play with it on #409 branch.
dir: cmd
CGO_ENABLED=0 running alpine13.10 go13 and go install ./...
dir:root
CGO_ENABLED=0 alpine13.10 go13 and go install ./...
dir:root
alpine13.10 go13 and go install ./...
dir:root
running alpine13.10 go13 and go run build/ci.go install
installing build-base (gcc 8.4.0)
dir:root
running alpine13.10 go13 and go run build/ci.go install
installing build-base (gcc 8.4.0)
dir:root
running alpine13.10 go13 and go install ./...
using FROM n0madic/alpine-gcc:7.4.0 as builder
and building go 1.13.4 from source
Step 23/29 : RUN go install ./...
using FROM n0madic/alpine-gcc:7.4.0 as builder
and building go 1.13.4 from source CGO_ENABLED=0
using FROM n0madic/alpine-gcc:7.4.0 as builder
RUN go run build/ci.go install
using FROM n0madic/alpine-gcc:7.4.0 as builder
and building go 1.13.4 from source CGO_ENABLED=0 and build/ci.go install
Context
Example dockerfile with gcc7 and manually installing go13:
The text was updated successfully, but these errors were encountered: