C++項目怎麼適用不同的linux系統？

12-31

有個C++項目，用到了很多開源軟體，每次部署到不同linux系統時，需要先編譯開源軟體成庫文件，再編譯項目庫文件，再編譯項目進程，移植性不好。嘗試過全靜態編譯，最終還是依賴一些動態庫。
求解決部署問題的思路。謝謝！

打包成docker的image就可以了。

嫌docker太重的話，直接複製根目錄也可以，刪掉不需要的，然後在目標機器上用systemd-nspawn跑。

或者runc（Open Container Project ）、rkt（GitHub - coreos/rkt: rkt is an App Container runtime for Linux ）等等，這些都是一樣原理的。

=== update ===

不用說C++程序，跑一整個其他發行版都是輕而易舉的事情，看下面man systemd-nspawn的examples部分。systemd-nspawn這個命令是systemd自帶的，用systemd的系統應該都有，沒有docker那樣麻煩。跑單個應用的話，用這個就行了，至少都比直接跑安全些。

EXAMPLES Example 1. Download a Fedora image and start a shell in it


           # machinectl pull-raw --verify=no http://ftp.halifax.rwth-aachen.de/fedora/linux/releases/21/Cloud/Images/x86_64/Fedora-Cloud-Base-2

0141203-21.x86_64.raw.xz

           # systemd-nspawn -M Fedora-Cloud-Base-20141203-21
       This downloads an image using machinectl(1) and opens a shell in it.
       Example 2. Build and boot a minimal Fedora distribution in a container
           # dnf -y --releasever=23 --installroot=/srv/mycontainer --disablerepo="*" --enablerepo=fedora --enablerepo=updates install systemd p

asswd dnf fedora-release vim-minimal

           # systemd-nspawn -bD /srv/mycontainer
       This installs a minimal Fedora distribution into the directory /srv/mycontainer/ and then boots an OS in a namespace container in

       it.
       Example 3. Spawn a shell in a container of a minimal Debian unstable distribution
           # debootstrap --arch=amd64 unstable ~/debian-tree/

           # systemd-nspawn -D ~/debian-tree/
       This installs a minimal Debian unstable distribution into the directory ~/debian-tree/ and then spawns a shell in a namespace

       container in it.
       Example 4. Boot a minimal Arch Linux distribution in a container
           # pacstrap -c -d ~/arch-tree/ base

           # systemd-nspawn -bD ~/arch-tree/

This installs a minimal Arch Linux distribution into the directory ~/arch-tree/ and then boots an OS in a namespace container in it.

以原碼發布，用 cmake 或 autotools 等工具解決編譯期依賴，在各個系統上編譯安裝。

或者你也可以為各個發行版打包成 deb、rpm 之類的包。

以後的話，或許可以用 xdg-app 或 snap。

到處編寫，到處調試，到處編譯，到處發布

如果是桌面軟體，還是直接cmake+flatpak吧。

編譯工具鏈中，cmake算是比較人性化的工具了。

分發軟體由於deb和rpm配置起來都很麻煩，還不如用flatpak直接搞定。（類似macOS下的dmg文件）

至於服務端軟體，還是自己建deb和rpm的源吧。

跨所有主流的Linux發行版發布Binary沒什麼好的辦法。只能這樣為各個發行版手動調整。如有可能，最好去限制一下客戶的Linux發行版。

不同的發行版總會有不同的。C++依賴的glibc/libstdc++/gcc的版本，各個發行版經常會不一樣。

auto tools該用還得用，有幾個真正開源的庫不支持的。即使一些較大的庫，比如boost之類的，沒有使用標準的編譯系統，但在大多數平台上還是豪不費力的。

flatpak（逃

你不依賴動態庫是不可能的，至少也得依賴glibc。

我大致上能想到兩種邏輯：

源代碼包的邏輯，使用autotools、cmake等構建工具進行開發庫搜索，並限制依賴庫的版本，如果不滿足就不生成。
發行版的邏輯，完全使用包管理器解決依賴和版本問題。

用萬能語言java吧

PHP程序猿路過

docker

學習反人類的autoconf和automake，或者新一點不那麼反人類cmake之類，整個unix/linux生態都是建立在源碼發布這個基礎上的，要習慣

主流Linux可以打deb包之類的。

非主流的Linux就別管它了。

一般來說。服務小白的軟體團隊都比較大。部署問題可以專人解決。

服務程序員的軟體呢？特么都服務程序員了還不讓人編譯嗎！

要想努力成為段子手，如何動腦子呢？

這個沒有非常通用的解決方法, 因為系統生態本身是開放的, 沒有事實上的統一的標準, 就只能藉助於源碼來調試,調優.

我的建議是只以幾個distro作為基準來提供, 建議以Ubuntu, SUSE, RHEL, Debian, CentOS為基礎, 這樣就基本上覆蓋了90%以上的商業用戶了.

其它平台, 以tar包的形式提供源碼構建.