Failed to compile under docker golang:alpine

[c0mm4nd]

Step 10/11 : RUN GOPROXY=$GOPROXY go test ./...
 ---> Running in 11eab791155a
go: downloading github.com/bytecodealliance/wasmtime-go v0.17.0
# github.com/bytecodealliance/wasmtime-go
/usr/lib/gcc/x86_64-alpine-linux-musl/9.2.0/../../../../x86_64-alpine-linux-musl/bin/ld: /go/pkg/mod/github.com/bytecodealliance/[email protected]/build/linux-x86_64/libwasmtime.a(std-3859b7e52a41a8fd.std.1o062trz-cgu.0.rcgu.o): in function `std::sys::unix::net::on_resolver_failure':
/rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd//src/libstd/sys/unix/net.rs:377: undefined reference to `__res_init'
collect2: error: ld returned 1 exit status

Dockerfile

FROM golang:alpine

ARG goproxy=https://goproxy.io
ARG in_china=0
ENV GOPROXY ${goproxy}

COPY . /build
WORKDIR /build

# RUN apk add build-base
RUN apk add --no-cache make gcc musl-dev linux-headers git
RUN GOPROXY=$GOPROXY go test ./...

It seems an upstream issue between wasmtime and alpine(musl)?

[alexcrichton]

Thanks for the report! This library uses CGO, however, and is as a result pretty dependant on the native C runtime. The prebuilt binaries checked into this repository and used on taggs only work with glibc, there's not a prebuilt binary for musl.

If you'd like, though, then we'd need to make a binary release for musl on wasmtime itself, and then that could get consumed here!

[c0mm4nd]

Docker is an important platform for deploying and distributing go applications, and the alpine container can effectively reduce the size of image. So it is worth to support it.

[tschneidereit]

Docker is an important platform for deploying and distributing go applications, and the alpine container can effectively reduce the size of image. So it is worth to support it.

I agree that this would be great to support for this reason, yes.

If you'd like, though, then we'd need to make a binary release for musl on wasmtime itself, and then that could get consumed here!

So IIUC we'd need to add a musl build config to Wasmtime, and optionally use that in wasmtime-go?

[c0mm4nd]

It would be best that being auto-selected in alpine but optional in other linux distro.

If it impossible, providing a guide about manually installing wasmtime in system and letting wasmtime-go use external library would be also great.

[srenatus]

So IIUC we'd need to add a musl build config to Wasmtime, and optionally use that in wasmtime-go?

I suppose if wasmtime was pushing a musl c-api tarball, we could use that here, and copy the file into build/ for the tags; from a the consuming side, it would then be a matter of importing

import (
    _ "github.com/bytecodealliance/wasmtime-go/build/linux-x86_64" # glibc
    _ "github.com/bytecodealliance/wasmtime-go/build/linux-x86_64-musl # musl
)

... but I could be missing something. 🤔

[simar7]

We're running into this with our project that uses OPA/wasm (which uses wasmtime-go internally). Does this mean wasmtime-go can't be used on an alpine base image until this is resolved?

[alexcrichton]

It should be possible to make a custom build of Wasmtime for Alpine using musl-libc, but otherwise no, there is no precompiled binary for musl libc for you to use.

[graywolf-at-work]

I've just hit this today, are there any specific steps I could help with?