综合大家的意见尝试初步总结一下：

首先是要确定目标系统的libc最低版本和kernel最低版本。
现在kernel版本基本都是4.x、5.x了，有syscall兼容问题的概率应该非常小，可以忽略。
前提都是假定目标linux发行版没有乱改syscall和libc。

1、最麻烦的办法，也是初期最可能使用的办法：
针对每个目标系统单独编译打包，或者是尝试用同一个包去部署，部署之前在实验室内测试出问题的话再针对这个目标系统单独编译打包。
这个方法最原始，但是working，只是工作量可能大。glibc自带、不自带都行，其他的库（包括libstdc++都可以）尽可能静态链接。

2、用LibcWrapGenerator/glibc_version_header/bingcc这三个的办法，编译任何动态库、可执行程序时都明确指定所引用到的GLIBC里的每个符号的精确版本。
顺带可以建立每个版本的GLIBC里的每个符号的版本号的数据库，只要输入一个符号，就能知道它最早出现在哪个版本的GLIBC里。
给定一个可执行程序/动态库，以及GLIBC版本号，用这个库可以直接判定二者的兼容性。

3、用PatchELF的hack办法，修改编译产物里的导入表，把导入表里的每个GLIBC符号的版本号抹掉，变成无版本号的符号。
有可能需要自己维护PatchELF这个工具。

4、用musl替换掉glibc。
musl某些函数性能比stdc++慢，这个问题目前不影响什么，后期也可以从其他库里扒性能好点的实现代码。
可能需要自己维护musl的工具链？不光是发布编译时用，日常开发调试时也要用。
musl可能已经支持所有国产的芯片平台？
暂不考虑用libc++替换libstdc++，因为只要把libstdc++静态链接就行。

5、在Alpine上或者开发机的linux上全静态链接

6、使用docker发布


【 在 Snija 的大作中提到: 】
: 另外可以参考下rhel/centos下面那个gcc-toolset, 高版本的gcc编译出来的程序仍然用的是系统的libstdc++
: 发自「今日水木 on Android」
--
FROM 222.130.137.*