Hacker News Reader

Comment by random3 | Hacker News Reader

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.

View on HN

    # 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

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

Thank you! I missed this doc https://news.ycombinator.com/formatdoc

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).

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.

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.

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.

Yes, I completely agree—we’re saying the same thing.

Same with FreeBSD and most other systems really. It's very frustrating that the Go people decided that the Linux way is appropriate everywhere.

Directly touching syscalls instead of using libc sucks because a) it kills LD_PRELOAD hooks and b) it makes porting to new architectures extremely time-consuming. (e.g. I'm porting lots of stuff to FreeBSD/aarch64 — most languages were rather trivial to port, Go took months and several people)

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

Reply on news.ycombinator.com