这是一个创建于 81 天前的主题，其中的信息可能已经有所发展或是发生改变。
如果开发一个 Linux 程序，依赖了很多第三方库，大家是直接引用系统中的？ 发现前人是把所有的库都自己编译了一下，然后放到/usr/local/xxx/xxx 下，如果库之间有依赖，编译的时候也要改，然后程序中都是依赖/usr/local/xxx/下的库，完全不引用/usr/lib 或者/usr/local/lib 下的，感觉有点奇怪
 |
1
vcn8yjOogEL 81 天前 via Android
看你怎么打包了, 一般为了省空间都是尽可能动态链接的
想简单点就打成 Flatpak 这类通用包, 缺点就是会有重复依赖 |
 |
2
adoal 81 天前
这种一般是因为，没办法决定客户生产环境用的发行版 and/or 版本，所以/usr/lib 下的库（正常来说应该都是发行版打包的），版本不可控，就会有兼容性问题。如果要去适配和测试多个发行版 and/or 版本，势必增加很大的工作量，大多数公司不会愿意接受这种没有直接产生效益的成本。所以宁肯草台一点，自己打包主要依赖，至少做到行为可控。
话说，Windows 下面应用软件的第三方依赖不都是这么搞的么。 |
 |
3
MiketsuSmasher 80 天前
直接静态编译试试？
|
 |
4
passive 80 天前 via Android
自己编译库+rpath
或者给每个 distro 都打包一份，用 distro 自己的 lib 或者 container 静态编译连 lgpl 都逃不过 |
 |
5
weidaizi 80 天前
看你的包用来做啥吧
* 如果是打包贡献给社区，就编译自己的就好了，最好也加个 rpath (毕竟现在 runpath 的对间接依赖已经无效了)，给外部打 portable 比较方便 * 如果是自己/公司的项目，可以全部依赖都放一起，设置好 rpath ，随便解压到哪里都可以直接跑 |
 |
6
ysc3839 79 天前 via Android
系统包管理有提供就用系统的，否则自己编译，如果是单文件就静态链接，多文件就跟随程序一起打包，不安装进系统
|
 |
7
chhtdd 79 天前
./thridparty
|
 |
8
tomychen 68 天前
从某种程度上来讲,我倒觉得是个好习惯 ,虽然编译过程麻烦了点,但有个好处是最小化依赖系统库,也避免了更新系统,或者更新第三库的时候和系统原有的冲突了.
典型: macport 和 brew |
Select Language