Linux 程序的第三方库依赖

[alexlee0728]

如果开发一个 Linux 程序，依赖了很多第三方库，大家是直接引用系统中的？ 发现前人是把所有的库都自己编译了一下，然后放到/usr/local/xxx/xxx 下，如果库之间有依赖，编译的时候也要改，然后程序中都是依赖/usr/local/xxx/下的库，完全不引用/usr/lib 或者/usr/local/lib 下的，感觉有点奇怪

[vcn8yjOogEL]

看你怎么打包了, 一般为了省空间都是尽可能动态链接的
想简单点就打成 Flatpak 这类通用包, 缺点就是会有重复依赖

[adoal]

这种一般是因为，没办法决定客户生产环境用的发行版 and/or 版本，所以/usr/lib 下的库（正常来说应该都是发行版打包的），版本不可控，就会有兼容性问题。如果要去适配和测试多个发行版 and/or 版本，势必增加很大的工作量，大多数公司不会愿意接受这种没有直接产生效益的成本。所以宁肯草台一点，自己打包主要依赖，至少做到行为可控。

话说，Windows 下面应用软件的第三方依赖不都是这么搞的么。

[MiketsuSmasher]

直接静态编译试试？

[passive]

自己编译库+rpath

或者给每个 distro 都打包一份，用 distro 自己的 lib

或者 container

静态编译连 lgpl 都逃不过

[weidaizi]

看你的包用来做啥吧
* 如果是打包贡献给社区，就编译自己的就好了，最好也加个 rpath (毕竟现在 runpath 的对间接依赖已经无效了)，给外部打 portable 比较方便
* 如果是自己/公司的项目，可以全部依赖都放一起，设置好 rpath ，随便解压到哪里都可以直接跑

[ysc3839]

系统包管理有提供就用系统的，否则自己编译，如果是单文件就静态链接，多文件就跟随程序一起打包，不安装进系统

[chhtdd]

./thridparty

[tomychen]

从某种程度上来讲,我倒觉得是个好习惯 ,虽然编译过程麻烦了点,但有个好处是最小化依赖系统库,也避免了更新系统,或者更新第三库的时候和系统原有的冲突了.

典型: macport 和 brew