crashlytics:symbols:upload: bundled Linux dump_syms.bin is glibc-linked, unusable on musl/Alpine — add a breakpad-binary override (or ship a static binary)

[qeepcologne]

Feature request

crashlytics:symbols:upload extracts and runs a bundled dump_syms.bin that is dynamically linked against glibc (ELF interpreter /lib64/ld-linux-x86-64.so.2). On a musl-based distro (Alpine Linux — extremely common for CI images) the binary cannot execute, so breakpad symbol generation fails. There is no CLI way to supply an alternative binary, and the alternative generator does not work for our case (see below), so the only way out is an out-of-band hack.

Please either:

1. Add a CLI option (flag or env var) to override the breakpad/dump_syms binary used by crashlytics:symbols:upload — parity with the Crashlytics Gradle plugin, which already accepts a breakpadBinary override. This requires no commitment to "support Alpine"; it just lets musl users point at a statically-linked dump_syms they provide. (preferred — smallest change)
2. Or statically link (or ship a musl build of) the bundled Linux dump_syms.bin.

Environment

• firebase-tools 15.20.0 (installed via npm i -g firebase-tools)
• Alpine Linux (musl libc), x86_64, Docker CI image (Jenkins)
• Flutter Android app, uploading native (NDK) Crashlytics symbols

What happens

firebase crashlytics:symbols:upload --generator=breakpad --app=$APP_ID ./debug extracts .crashlytics/dump_syms.bin and then fails trying to execute it, because that binary is a glibc-dynamic ELF:

$ file .crashlytics/dump_syms.bin
ELF 64-bit LSB ... dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux ...

Alpine has no /lib64/ld-linux-x86-64.so.2 (musl), so the loader is missing and dump_syms.bin can't run → "Crashlytics found no symbols".

Why the usual escapes don't work

• --generator=csym produces empty symbol files for Flutter's DWARF debug info ("Crashlytics found no symbols"). Only the breakpad generator (dump_syms.bin) parses Flutter's native symbols correctly, so csym is not a usable alternative for Flutter apps.
• gcompat (musl's glibc shim) owns /lib64/ld-linux-x86-64.so.2 for NDK/ninja toolchain use, but it cannot actually run the glibc-linked dump_syms.bin.

Current workaround (evidence this is purely a linking issue)

Install real glibc beside musl and repoint the interpreter, then re-run:

# 1st call extracts dump_syms.bin, then fails to run it under musl (output captured)
firebase crashlytics:symbols:upload --generator=breakpad --app=$APP_ID ./debug || true
patchelf --set-interpreter /usr/glibc-compat/lib/ld-linux-x86-64.so.2 .crashlytics/dump_syms.bin
firebase crashlytics:symbols:upload --generator=breakpad --app=$APP_ID ./debug   # now succeeds

The real glibc comes from sgerrand/alpine-pkg-glibc, whose final release is 2.35-r1 (the project is dormant). So this workaround is fragile: an --allow-untrusted apk from an unmaintained project, pinned at glibc 2.35 forever — it will break the day dump_syms.bin is rebuilt against a newer glibc symbol, with no newer package available.

A CLI breakpad-binary override (option 1) would let us drop all of this and supply a statically-linked dump_syms instead.

Steps to reproduce

1. Alpine x86_64 image with firebase-tools installed via npm.
2. Run firebase crashlytics:symbols:upload --generator=breakpad --app=<APP_ID> <unstripped-libs-dir>.
3. Observe failure; inspect the extracted .crashlytics/dump_syms.bin with file → glibc-dynamic, interpreter /lib64/ld-linux-x86-64.so.2.