Node.js SDK 3.0.20+ requires glibc 2.39, breaking on AWS Lambda / Vercel / Amazon Linux 2023

[AttackOnMorty]

Summary

Starting from longport@3.0.20, the native binding (longport-linux-x64-gnu) requires glibc 2.39, which is newer than what most serverless platforms provide. This causes ERR_DLOPEN_FAILED at runtime on:

• Vercel (Amazon Linux 2023, glibc 2.34)
• AWS Lambda (Amazon Linux 2023, glibc 2.34)
• Any host running Amazon Linux 2023, RHEL 9, Ubuntu 22.04, or similar

Reproduction

# On Amazon Linux 2023 (or Vercel Lambda):
node -e "require('longport')"

Error:

Error: /lib64/libc.so.6: version 'GLIBC_2.39' not found
  (required by node_modules/longport/longport.linux-x64-gnu.node)

Note: longport's index.js catches this and rethrows a misleading generic error:

Cannot find native binding. npm has a bug related to optional dependencies…

This hides the real ERR_DLOPEN_FAILED / glibc mismatch.

Version comparison

longport version	Max glibc required	Compatible with AL2023 (glibc 2.34)?
3.0.18	2.34	✅ Yes
3.0.20	2.39	❌ No
3.0.21	2.39	❌ No
3.0.22	2.39	❌ No

Verified by grepping the GLIBC version symbols from each .node binary:

grep -aoP 'GLIBC_[\d.]+' longport.linux-x64-gnu.node | sort -uV | tail -1

Workaround

Pin to longport@3.0.18 (the newest version compiled against glibc ≤ 2.34).

Suggestions

1. Compile against an older glibc (e.g., 2.31 or 2.34) to maintain compatibility with current serverless platforms. Many Rust projects use cross or Docker images with older base distros for this.
2. Improve the error message — the catch-all "Cannot find native binding" in index.js hides the real dlopen error. Surfacing loadErrors would save users significant debugging time.
3. Publish a musl variant for newer versions (only available up to 3.0.18 currently).

Environment

• Platform: Vercel (Amazon Linux 2023, glibc 2.34)
• Node.js: v24.13.0
• longport: 3.0.22
• Arch: x86_64

[Shinku1014]

Same problem in using python lib; newest longbridge 4.0.0 requires glibc 2.39, but my device only 2.34