3 ms·

We were using Alpine Docker images. Every few months the docker build would fail with some random glibc / musl glibc-compat new issue. The docker file is full

We were using Alpine Docker images. Every few months the docker build would fail with some random glibc / musl glibc-compat new issue. The docker file is full of comments like the following: # libc6-compat needed by outdated grpc-tools # we get # sh: node_modules/grpc-tools/bin/protoc: not found # can be removed if we remove grpc-tools and assume an existing protoc for dev # i.e. developers would independently intall protoc in order to generate # grpc-web # we install separate from the packages above to avoid a failure noticed on # 2019-11-01 # apk update && apk add protobuf grpc gcompat libc6-compat # ERROR: unsatisfiable constraints: # musl-1.1.20-r4: # breaks: libc6-compat-1.1.24-r0[musl=1.1.24-r0] # satisfies: musl-utils-1.1.20-r4[musl=1.1.20-r4] #RUN apk add libc6-compat Bottom line is that it's awesome to have something lean like Alpine, but that can hardly justify the effort to maintain it. It feels like Linux two decades ago.

MuffinFlavored 7y ago
# libc6-compat needed by outdated grpc-tools # we get # sh: node_modules/grpc-tools/bin/protoc: not found # can be removed if we remove grpc-tools and assume an existing protoc for dev # i.e. developers would independently intall protoc in order to generate # grpc-web # we install separate from the packages above to avoid a failure noticed on # 2019-11-01 # apk update && apk add protobuf grpc gcompat libc6-compat # ERROR: unsatisfiable constraints: # musl-1.1.20-r4: # breaks: libc6-compat-1.1.24-r0[musl=1.1.24-r0] # satisfies: musl-utils-1.1.20-r4[musl=1.1.20-r4] #RUN apk add libc6-compat formatted that for you
- jhalstead 7y ago
  And for mobile readers ;) # libc6-compat needed by outdated grpc-tools # we get # sh: node_modules/grpc-tools/bin/protoc: not found # can be removed if we remove grpc-tools and assume an existing protoc for dev # i.e. developers would independently intall protoc in order to generate # grpc-web # we install separate from the packages above to avoid a failure noticed on # 2019-11-01 # apk update && apk add protobuf grpc gcompat libc6-compat # ERROR: unsatisfiable constraints: # musl-1.1.20-r4: # breaks: libc6-compat-1.1.24-r0[musl=1.1.24-r0] # satisfies: musl-utils-1.1.20-r4[musl=1.1.20-r4] #RUN apk add libc6-compat
- random3 7y ago
  Thank you! I missed this doc https://news.ycombinator.com/formatdoc https://news.ycombinator.com/formatdoc
Scarbutt 7y ago
That's the reason I don't use alpine for containers and just keep using debian.
throwaway894345 7y ago
This feels like more of a criticism of libc/glibc to me. In either case, it makes me glad that Go doesn't lean so heavily on libc/glibc (even though everyone complains endlessly about bugs like those that happened that one time MacOS made a syscall API change to the effect that users needed to update their binaries).
- johncolanduoni 7y ago
  I think it was a good decision to cut out libc/MSVC on Linux and Windows, where they lead to dependencies that prevent you from freely building on one system and running on another. But for macOS this doesn’t make much sense; the facilities Go needs from libSystem are overwhelmingly backwards compatible and the macOS toolchain/ABI handles using weak linking to conditionally link to newer features very well. AFAICT using system calls directly on macOS is no better a way to accomplish those objectives than calling ntdll directly instead of Win32 APIs on Windows.
  - throwaway894345 7y ago
    I guess I wasn't intending to advocate for hitting syscalls directly so much as I was advocating against targeting libc and calling it a day. Libc is a leaky interface (as previously discussed, things randomly break if the implementation isn't glibc which itself has lots of issues), and I like that Go targets each platform individually (even if there are issues with its macos bindings). It works out very well in practice, and even the issues with the macos bindings are nigh insignificant.
    - johncolanduoni 7y ago
      They could still target each platform individually even while using libc APIs where applicable only on macOS, since those are often the lowest level stable options available on Mac. My point is that there’s no reason you need to take exactly the same approach on each platform to achieve the same goals.
      - 7y ago

MuffinFlavored 7y ago

# libc6-compat needed by outdated grpc-tools # we get # sh: node_modules/grpc-tools/bin/protoc: not found # can be removed if we remove grpc-tools and assume an existing protoc for dev # i.e. developers would independently intall protoc in order to generate # grpc-web # we install separate from the packages above to avoid a failure noticed on # 2019-11-01 # apk update && apk add protobuf grpc gcompat libc6-compat # ERROR: unsatisfiable constraints: # musl-1.1.20-r4: # breaks: libc6-compat-1.1.24-r0[musl=1.1.24-r0] # satisfies: musl-utils-1.1.20-r4[musl=1.1.20-r4] #RUN apk add libc6-compat formatted that for you

jhalstead 7y ago
And for mobile readers ;) # libc6-compat needed by outdated grpc-tools # we get # sh: node_modules/grpc-tools/bin/protoc: not found # can be removed if we remove grpc-tools and assume an existing protoc for dev # i.e. developers would independently intall protoc in order to generate # grpc-web # we install separate from the packages above to avoid a failure noticed on # 2019-11-01 # apk update && apk add protobuf grpc gcompat libc6-compat # ERROR: unsatisfiable constraints: # musl-1.1.20-r4: # breaks: libc6-compat-1.1.24-r0[musl=1.1.24-r0] # satisfies: musl-utils-1.1.20-r4[musl=1.1.20-r4] #RUN apk add libc6-compat
random3 7y ago
Thank you! I missed this doc https://news.ycombinator.com/formatdoc https://news.ycombinator.com/formatdoc

Scarbutt 7y ago

That's the reason I don't use alpine for containers and just keep using debian.

throwaway894345 7y ago

This feels like more of a criticism of libc/glibc to me. In either case, it makes me glad that Go doesn't lean so heavily on libc/glibc (even though everyone complains endlessly about bugs like those that happened that one time MacOS made a syscall API change to the effect that users needed to update their binaries).

johncolanduoni 7y ago
I think it was a good decision to cut out libc/MSVC on Linux and Windows, where they lead to dependencies that prevent you from freely building on one system and running on another. But for macOS this doesn’t make much sense; the facilities Go needs from libSystem are overwhelmingly backwards compatible and the macOS toolchain/ABI handles using weak linking to conditionally link to newer features very well. AFAICT using system calls directly on macOS is no better a way to accomplish those objectives than calling ntdll directly instead of Win32 APIs on Windows.
- throwaway894345 7y ago
  I guess I wasn't intending to advocate for hitting syscalls directly so much as I was advocating against targeting libc and calling it a day. Libc is a leaky interface (as previously discussed, things randomly break if the implementation isn't glibc which itself has lots of issues), and I like that Go targets each platform individually (even if there are issues with its macos bindings). It works out very well in practice, and even the issues with the macos bindings are nigh insignificant.
  - johncolanduoni 7y ago
    They could still target each platform individually even while using libc APIs where applicable only on macOS, since those are often the lowest level stable options available on Mac. My point is that there’s no reason you need to take exactly the same approach on each platform to achieve the same goals.
    - 7y ago