一是某些不能全静态，比如有使用GUI的GTK库，GTK可以认为是没法全静态链接的
二是libc和os的接口，也就是syscall接口。一般内核版本变动不大是没啥问题的。

除此之外只是elf的尺寸问题。


【 在 lwp 的大作中提到: 】
: 所以我只是想问,除了这两个要静态链接,还有没有其它问题要注意的?
:
--
FROM 123.114.4.*

生成兼容的二进制，问题主要在API版本依赖和ABI，而不是编译器或所用语言版本。对运行环境那边考虑的是cpu体系结构，操作系统，ABI，库版本这些。你把这个事情考虑成交叉编译会清楚一些。

静态链接libgcc和libstdc++可以解决一部分问题，前者主要是gcc版本的差异，后者主要是c++标准库的差异。你依然可能遇到glibc的版本依赖问题（这和c++以及gcc版本都无关），第三方c++库的依赖问题，甚至系统内核版本问题。

省事的办法，比如docker，把整个依赖环境都带上；或者想办法全静态编译。
【 在 lwp 的大作中提到: 】
: 编译的时候用上-static-libgcc  -static-libstdc++
:
: 把这两个东西都静态链进去,是不是就行了?
: ...................
--
FROM 114.254.10.*

就这也不顶用。首先目标环境的glibc版本大概率降挺多的，也就是说你大概率不兼容。其实你这样写个hellowold都大概率不兼容，试试就知道了。
你报个linux发行版的版本都有用一点。

考虑到你要用c++20，建议你分别考虑如下几种解决方案：
1. 用crosstool-ng之类工具，配置目标环境的系统内核版本，glibc版本，构建交叉编译环境，之后从源代码安装目标环境对应版本的依赖库，最后静态链接所有c++语言接口的库和libgcc，其他c语言接口库可以动态链接。
2. 用crosstool-ng之类工具，配置目标环境版本，用musl库，构建交叉编译环境，从源代码安装所有依赖库，然后尝试全静态编译你的程序。
3. 用 docker。
【 在 lwp 的大作中提到: 】
: 我发贴是不是非要说gcc11.3的编译器编的程序在gcc7.5的环境上跑才行
:
: 【 在 dormouseBHU 的大作中提到: 】
: ...................
--
FROM 114.254.10.*

对了，还有个问题：

glibc里有些功能是会动态加载so的（虽然你的代码不一定会触发，但需要了解并测试一下），所以最好是用uClibc或者musl libc 之类的来全静态链接，而不是用libgcc。

还有抛异常的问题：
There are several situations in which an application should use the shared libgcc instead of the static version. The most common of these is when the application wishes to throw and catch exceptions across different shared libraries. In that case, each of the libraries as well as the application itself should use the shared libgcc.

【 在 lwp 的大作中提到: 】
: 编译的时候用上-static-libgcc  -static-libstdc++
: 把这两个东西都静态链进去,是不是就行了?
:
--
FROM 222.130.138.*