Gpg2 库依赖树
Gpg2 libraries dependency tree
是否有一些 Gpg2 使用的库的依赖树或图,例如 libgpg-error
或 libassuan &c.
?
或者另一种方法来确定在其中一个获得新版本后我需要重新编译哪些?例如。 libgpg-error 是,据我所知,非常基本的一个,所以如果它升级了,也许所有其他的都应该重新编译?
我有时 运行 在升级库后遇到麻烦我无法编译新版本的 Gpg2 因为它试图 link 旧的,已经删除的那个库版本(我有一个 non-standard 的目录结构),并因 'cannot find library' 而崩溃。经过一些(不是很彻底的)研究,我认为这是由于从升级之前构建的其他库中获取该特定库版本的信息造成的。
例如:我最近将 libgpg-error 升级到 1.32。今天我尝试(但失败了(不得不手动修复))编译 Gpg 2.2.10。
失败的命令是这个(缩写):
/usr/local/bin/gcc -std=gnu99 ... \
-I/usr/local/libgpg-error-1.31/include \
-I/usr/local/libgpg-error-1.25/include \
-I/usr/local/libgpg-error-1.31/include \
-I/usr/local/libgpg-error-1.32/include \
-o dirmngr dirmngr.o server.o crlcache.o crlfetch.o certcache.o ... \
../common/libcommonpth.a -lresolv \
-L/usr/local/libgpg-error-1.31/lib -lgpg-error \
-L/usr/local/libgpg-error-1.31/lib -lgpg-error \
-L/usr/local/libgpg-error-1.25/lib -lgpg-error \
...
注意它如何尝试包含 libgpg-error headers 的 1.25、1.31 和 1.32 版本以及 libgpg-error 的 link 版本 1.25 和 1.31(但不是 1.32)。因此,尽管磁盘上不再存在这些版本的 none,但当前版本除外,即 1.32。但是,当编译其他一些库时,它们会更早出现。
似乎没有可用的答案,所以我至少尝试查看各个库的 configure
脚本,这是(非常没有任何保证)我想出的一些依赖关系图和建议的编译顺序:
level 0
| libgpg-error
| nPth
level 1
| libgcrypt (libgpg-error)
| libksba (libgpg-error)
| libassuan (libgpg-error)
level 2
| ntbTLS (libgpg-error, libgcrypt, libksba)
| pinentry (libgpg-error, libassuan)
level N
| gpg2 (libgpg-error, libgcrypt, libassuan, libksba, nPth) [pinentry, ntbTLS]
level N+1
| GPGME (libgpg-error, libassuan)
level N+2
| GPA (libgpg-error, libassuan, GPGME)
(根据 Ben 在其评论中的建议进行编辑。)
是否有一些 Gpg2 使用的库的依赖树或图,例如 libgpg-error
或 libassuan &c.
?
或者另一种方法来确定在其中一个获得新版本后我需要重新编译哪些?例如。 libgpg-error 是,据我所知,非常基本的一个,所以如果它升级了,也许所有其他的都应该重新编译?
我有时 运行 在升级库后遇到麻烦我无法编译新版本的 Gpg2 因为它试图 link 旧的,已经删除的那个库版本(我有一个 non-standard 的目录结构),并因 'cannot find library' 而崩溃。经过一些(不是很彻底的)研究,我认为这是由于从升级之前构建的其他库中获取该特定库版本的信息造成的。
例如:我最近将 libgpg-error 升级到 1.32。今天我尝试(但失败了(不得不手动修复))编译 Gpg 2.2.10。
失败的命令是这个(缩写):
/usr/local/bin/gcc -std=gnu99 ... \
-I/usr/local/libgpg-error-1.31/include \
-I/usr/local/libgpg-error-1.25/include \
-I/usr/local/libgpg-error-1.31/include \
-I/usr/local/libgpg-error-1.32/include \
-o dirmngr dirmngr.o server.o crlcache.o crlfetch.o certcache.o ... \
../common/libcommonpth.a -lresolv \
-L/usr/local/libgpg-error-1.31/lib -lgpg-error \
-L/usr/local/libgpg-error-1.31/lib -lgpg-error \
-L/usr/local/libgpg-error-1.25/lib -lgpg-error \
...
注意它如何尝试包含 libgpg-error headers 的 1.25、1.31 和 1.32 版本以及 libgpg-error 的 link 版本 1.25 和 1.31(但不是 1.32)。因此,尽管磁盘上不再存在这些版本的 none,但当前版本除外,即 1.32。但是,当编译其他一些库时,它们会更早出现。
似乎没有可用的答案,所以我至少尝试查看各个库的 configure
脚本,这是(非常没有任何保证)我想出的一些依赖关系图和建议的编译顺序:
level 0
| libgpg-error
| nPth
level 1
| libgcrypt (libgpg-error)
| libksba (libgpg-error)
| libassuan (libgpg-error)
level 2
| ntbTLS (libgpg-error, libgcrypt, libksba)
| pinentry (libgpg-error, libassuan)
level N
| gpg2 (libgpg-error, libgcrypt, libassuan, libksba, nPth) [pinentry, ntbTLS]
level N+1
| GPGME (libgpg-error, libassuan)
level N+2
| GPA (libgpg-error, libassuan, GPGME)
(根据 Ben 在其评论中的建议进行编辑。)