谢谢。我学习一下你说的这个部署方式
不过最终可能不会用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.*

另外这种需求就不该用cpp，找罪受

【 在 z16166 的大作中提到: 】
:
: 1、编译器是gcc。需要在多种linux平台上运行，这些平台上自带的libstdc++.so可能差异较大。
:
: 2、但是我又想用C++20（新版本std带来的好处，不用就是暴殄天物？还有就是一部分代码来自MSVC，MSVC已经完全支持C++20），而不是限定在C++11或者C++14。
:

#发自zSMTH@YAL-AL10
--
FROM 110.184.4.*

我这个需求只能用c/cpp/rust这种实现

js/java之类的，不能用

go的话，估计还得调用C代码

【 在 MH730 的大作中提到: 】
: 另外这种需求就不该用cpp，找罪受
:
: #发自zSMTH@YAL-AL10
--
修改:z16166 FROM 222.130.137.*
FROM 222.130.137.*