- 主题:需要在多种linux平台上运行的代码，怎么选择编译器版本？
1、编译器是gcc。需要在多种linux平台上运行，这些平台上自带的libstdc++.so可能差异较大。
2、但是我又想用C++20（新版本std带来的好处，不用就是暴殄天物？还有就是一部分代码来自MSVC，MSVC已经完全支持C++20），而不是限定在C++11或者C++14。
目前的想法是：
1、用gcc 11或者12，这样能支持大部分c++20特性。
2、如果和os目录下的libstdc++.so不兼容，那么在自己目录下自带一个libstdc++.so。
但这有个新的问题，libstdc++和os自带的libgcc的接口兼容问题。
为了避免这个问题，可以采用全部静态链接到libstdc++和libgcc，但同样有libgcc和os接口兼容的问题（虽然概率越来越小）。如果用-static全部静态链接，概率会增大，不可取。
大家在实践中怎么搞定这个问题的？还是说就用各目标平台能支持的C++11/14/17/20中最低的那个std完事？
--
修改:z16166 FROM 222.130.137.*
FROM 222.130.137.*
最后的部署，没法虚拟机。
最好是只需要针对某个架构编译一次，就能部署在同架构的不同版本上。
再差点的，是针对同架构的不同版本，每个版本都编译一次。
【 在 ziqin 的大作中提到: 】
: 虚拟机大法啊
: 一个target platform 一个虚拟机 纯独立编译呗
--
修改:z16166 FROM 222.130.137.*
FROM 222.130.137.*
客户端软件，用不了docker
【 在 jimmycmh 的大作中提到: 】
: docker大法啊，所有依赖全打在容器里，到哪都一样
--
FROM 222.130.137.*
第三方库都可以静态库链接
【 在 DoorWay 的大作中提到: 】
: 你的第二条，必然导致有些发行版本不能用。
: 就是纯开源的软件，我记得^_^ sudo apt-get install 时也记得经常遇到请升级gcc的提示。如果你的软件依赖第三方包，出问题概率继续加大。
: 取主流版本的最大公约数吧，先弄出来。碰见冷门版本再说。
: ...................
--
FROM 222.130.137.*
我这个恰恰用不了，带有driver，是逃逸了docker的。
【 在 jimmycmh 的大作中提到: 】
: docker容器运行起来就是个普通进程，基本没见过用不了的程序
:
--
FROM 222.130.137.*
谢谢。我学习一下你说的这个部署方式
不过最终可能不会用docker，因为可能无法阻止用户用docker命令轻松停掉我的程序。
【 在 jimmycmh 的大作中提到: 】
: kernel module？没问题啊，用privileged mode
: 另外，不懂逃逸docker是什么意思
: docker不过是layered fs加namespace，跟普通进程基本是没区别的
: ...................
--
修改:z16166 FROM 222.130.137.*
FROM 222.130.137.*
appimage只解决打包问题，libstdc++和glibc的兼容问题依旧存在。
它的文档写的原则是：用最老的那个目标系统里的libstdc++.so.6
不过对于glibc，它推荐了三种可能的方式，值得研究：
LibcWrapGenerator or glibc_version_header or bingcc.
https://docs.appimage.org/reference/best-practices.html?highlight=libstdc
libstdc++.so.6?
As a general rule of thumb, please use no libstdc++.so.6 newer than the one that comes with the oldest distribution that you still want to support, i.e., the oldest still-supported LTS version of Ubuntu.
【 在 AudiDoggie 的大作中提到: 】
: 打包成appimage格式？
:
--
修改:z16166 FROM 222.130.137.*
FROM 222.130.137.*
有个简单gui
全静态的问题是syscall兼容，万一
静态链接到libgcc还有这个抛异常的问题：
-shared-libgcc
-static-libgcc
On systems that provide libgcc as a shared library, these options force the use of either the shared or static version, respectively. If no shared version of libgcc was built when the compiler was configured, these options have no effect.
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.
Therefore, the G++ driver automatically adds -shared-libgcc whenever you build a shared library or a main executable, because C++ programs typically use exceptions, so this is the right thing to do.
If, instead, you use the GCC driver to create shared libraries, you may find that they are not always linked with the shared libgcc. If GCC finds, at its configuration time, that you have a non-GNU linker or a GNU linker that does not support option --eh-frame-hdr, it links the shared version of libgcc into shared libraries by default. Otherwise, it takes advantage of the linker and optimizes away the linking with the shared version of libgcc, linking with the static version of libgcc by default. This allows exceptions to propagate through such shared libraries, without incurring relocation costs at library load time.
However, if a library or main executable is supposed to throw or catch exceptions, you must link it using the G++ driver, or using the option -shared-libgcc, such that it is linked with the shared libgcc.
https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 如果只依赖于 libc 和 libc++，没有搞 GUI 的话，可以用 alphine linux 搞全静态编译。
:
: 【 在 z16166 的大作中提到: 】
: : 1、编译器是gcc。需要在多种linux平台上运行，这些平台上自带的libstdc++.so可能差异较大。
--
修改:z16166 FROM 222.130.137.*
FROM 114.254.0.*
我这个需求只能用c/cpp/rust这种实现
js/java之类的，不能用
go的话，估计还得调用C代码
【 在 MH730 的大作中提到: 】
: 另外这种需求就不该用cpp，找罪受
:
: #发自zSMTH@YAL-AL10
--
修改:z16166 FROM 222.130.137.*
FROM 222.130.137.*
我看喷libc++的不少，一是喷性能，二是喷新的c++特性的实现慢
先解决多平台部署问题，再折腾（可能的）换库问题比较好。
【 在 Snija 的大作中提到: 】
: 为啥不用libc++?
: 发自「今日水木 on Android」
--
FROM 222.130.137.*