pyre.bin does not work on Debian Bullseye (glibc 2.31)

[filbranden]

Pyre Bug

Bug description
Latest pyre versions 0.9.21 and 0.9.22 from PyPI do not work on Debian Bullseye with glibc 2.31

Reproduction steps

$ sudo pip install pyre-check==0.9.21
$ pyre.bin
pyre.bin: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by pyre.bin)
pyre.bin: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by pyre.bin)
pyre.bin: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by pyre.bin)

Expected behavior
Expecting the binary to work, as it does on 0.9.19

$ sudo pip install pyre-check==0.9.19
$ pyre.bin
pyre: required COMMAND name is missing, must be one of 'analyze', 'check', 'code-navigation', 'infer', 'newanalyze', 'newcheck', 'newinfer', 'newserver', 'no-daemon-query' or 'server'.
Usage: pyre COMMAND …
Try 'pyre --help' for more information.

Logs

Output of pyre rage:

Versions
========
Client version: 0.9.21
Binary version: None

Configuration
=============
{
  "global_root": "/home/filipe",
  "dot_pyre_directory": "None",
  "only_check_paths": [],
  "excludes": [],
  "extensions": [],
  "ignore_all_errors": [],
  "other_critical_files": [],
  "search_path": [],
  "optional_search_path": [],
  "site_package_search_strategy": "none",
  "site_roots": [],
  "strict": false,
  "taint_models_path": [],
  "use_buck2": false
}

Watchman Watch-list
===================
{
    "version": "4.9.0",
    "roots": []
}

Additional context

Probably related to a build environment or ocaml compiler used during builds, regression seemed to be introduced between 0.9.19 and 0.9.21

[samwgoldman]

Thanks for the report! This is a really unfortunate issue, although a known one (#873). We build these binaries internally on machines where we don't control the build toolchain. We need to move these builds, but haven't prioritized that work yet. Honestly it kind of fell off my radar, so I'll take another look today.

[filbranden]

Thank you!

If I can make a suggestion, building in a container should be a good way to get reproducible builds without having the underlying host environment affect your system. Happy to provide you with a PR to build in a container in GitHub Actions if you'd like that (but it seems you moved away from GitHub Actions for a reason, so not sure if that's what you're looking for.)

Cheers!