Pin to glibc 2.34, and fix make deploy on MacOS

[d6e-automaton]

We'd been using frolvlad/alpine-glibc:alpine-3.15 as our base image for things, but that turns out to be a bad idea: that tag gets updated, every so often, with new versions of glibc -- and when it just got updated to glibc 2.35, that broke things for us(*). Instead, pin to alpine-3.15_glibc-2.34, which should be more stable.

And, also, ditch the trailing / in a find that was screwing up make deploy on MacOS. C'mon, MacOS – directory names do not have trailing / characters really, and you should never output them. 🙄

(*) Specifically:

"Normal" Alpine uses musl libc, but the alpine-glibc images include glibc in addition to musl: the musl libraries are still included. If you dynamically link using musl, you end up with an ELF shared object that uses /lib/ld-musl-x86_64.so.1 for the runtime link editor; if you dynamically link using glibc, the runtime link editor will be /lib/ld-linux-x86-64.so.2. If you try to use ld-musl-x86_64 for a glibc program, everything falls apart, you find unresolved symbols, and your binary won't run.

Unfortunately, alpine-3.15_glibc-2.35 symlinks ld-linux-x86-64 to ld-musl-x86_64 and bzzt, no dynamic glibc code is gonna work like that. Notably for our purposes, Envoy is a dynamically-linked glibc binary, so alpine-3.15_glibc-2.35 is out. (Yes, we could fix the symlink after installing, but... let's not.) And, even more unfortunately, when frolvlad bumped from glibc 2.34 to 2.35, they overwrote alpine-glibc:alpine-3.15 with alpine-glibc:alpine-3.15_glibc-2.35, thus breaking our new builds that referenced alpine-glibc:alpine-3.15.

So. Let's just pin the glibc version number too, going forward.

• I don't need to update CHANGELOG.md; this isn't user-visible.
• This is unlikely to impact how Ambassador performs at scale.
• My change is adequately tested.
• I didn't need to update DEVELOPING.md.
• The changes in this PR have been reviewed for security concerns and adherence to security best practices.

[LukeShu]

Thanks to @LukeShu for the help here!

FYI, if you do Co-authored-by: Luke Shumaker <[email protected]> in the commit message, GitHub understands that when its showing authorship in the UI.

[LukeShu]

Why is this PR from d6e-automaton?

[LukeShu]

Re: The PR description: "musl" is all-lowercase all the time

[kflynn]

Fixed the capitalization of musl, thanks. And... huh. I created this using gh pr create, so... yeah, why is it from d6e-automaton???

[LukeShu]

re: The libc breakage:

$ docker run --rm -it docker.io/frolvlad/alpine-glibc:alpine-3.15_glibc-2.35
/ # find / -name ld-*|xargs ls -l
lrwxrwxrwx    1 root     root            42 May 22 12:22 /lib/ld-linux-x86-64.so.2 -> /usr/glibc-compat/lib/ld-linux-x86-64.so.2
-rwxr-xr-x    1 root     root        604704 Sep 23  2021 /lib/ld-musl-x86_64.so.1
lrwxrwxrwx    1 root     root            26 May 22 12:22 /lib64/ld-linux-x86-64.so.2 -> /lib/libc.musl-x86_64.so.1
-rwxr-xr-x    1 root     root        227424 Mar 14 11:11 /usr/glibc-compat/lib/ld-linux-x86-64.so.2
lrwxrwxrwx    1 root     root            42 May 22 12:22 /usr/glibc-compat/lib64/ld-linux-x86-64.so.2 -> /usr/glibc-compat/lib/ld-linux-x86-64.so.2

$ docker run --rm -it docker.io/frolvlad/alpine-glibc:alpine-3.15_glibc-2.34
/ # find / -name ld-*|xargs ls -l
lrwxrwxrwx    1 root     root            42 May 22 12:07 /lib/ld-linux-x86-64.so.2 -> /usr/glibc-compat/lib/ld-linux-x86-64.so.2
-rwxr-xr-x    1 root     root        604704 Sep 23  2021 /lib/ld-musl-x86_64.so.1
lrwxrwxrwx    1 root     root            42 May 22 12:07 /lib64/ld-linux-x86-64.so.2 -> /usr/glibc-compat/lib/ld-linux-x86-64.so.2
-rwxr-xr-x    1 root     root        206776 Aug 19  2021 /usr/glibc-compat/lib/ld-linux-x86-64.so.2
lrwxrwxrwx    1 root     root            42 May 22 12:07 /usr/glibc-compat/lib64/ld-linux-x86-64.so.2 -> /usr/glibc-compat/lib/ld-linux-x86-64.so.2

Looks like a problem in frolvlad's scripts.

[kflynn]

Updated the comment to make it more clear that I'm not trying to call this a problem with glibc, but with frolvlad's image build.

[LukeShu]

Looks like it was introduced in sgerrand/alpine-pkg-glibc#171 changing the handling of Alpine's libc6-compat.

[LukeShu]

sgerrand/alpine-pkg-glibc#179 should be the fix