漂流記

Keep it simple, stupid.

用户工具

站点工具


zh:linuxfaq:version_compatibility

差别

这里会显示出您选择的修订版和当前版本之间的差别。

到此差别页面的链接

两侧同时换到之前的修订记录 前一修订版
zh:linuxfaq:version_compatibility [2019/06/11 22:29]
まこと 移除
— (当前版本)
行 1: 行 1:
-查看一个共享库的依赖,可以用ldd命令,如 
-<code> 
-makoto@box:~$ ldd /usr/lib64/libfontconfig.so 
-        linux-vdso.so.1 (0x00007ffc14399000) 
-        libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007fb0a6331000) 
-        libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007fb0a6107000) 
-        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb0a5eea000) 
-        libc.so.6 => /lib64/libc.so.6 (0x00007fb0a5b21000) 
-        libharfbuzz.so.0 => /usr/lib64/libharfbuzz.so.0 (0x00007fb0a58a3000) 
-        libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007fb0a556c000) 
-        libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fb0a535c000) 
-        libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007fb0a512a000) 
-        libz.so.1 => /lib64/libz.so.1 (0x00007fb0a4f15000) 
-        libm.so.6 => /lib64/libm.so.6 (0x00007fb0a4c0c000) 
-        /lib64/ld-linux-x86-64.so.2 (0x00007fb0a6809000) 
-</code> 
-结果的第2行表示依赖libfreetype.so.6,并且后面有绝对路径。如果依赖的库丢失了,则显示not found。有时候依赖的库发生了重大更新,导致文件名.so后面的数字发生改变,则需要重新编译了。偶尔强行创建一个软链接也可能运行,但不推荐。比如我的centos中shadowsocks-libev,ss-server依赖libmbedcrypto.so.0,而我只有libmbedcrypto.so.1,导致无法启动。我强行创建了libmbedcrypto.so.0,指向libmbedcrypto.so.1,也可以用。但我的经验是多数情况下失败。 
-有时会出现依赖的库存在但还是报错的情况。出错多数为undefined symbol。其发生原因是调用了依赖的库中某函数(函数名我们称为symbol),但依赖的库中没有该函数。我们如何检查呢? 
-输入命令<code>nm -D /usr/lib64/libfontconfig.so</code> 
-输出为 
  
-地址 类型 函数名 
- 
-的格式。其中类型为U则表示undefined symbol。 
-比如我的输出前30行 
-<code> 
-makoto@box:~$ nm -D /usr/lib64/libfontconfig.so|head -30 
-                 U FT_Done_Face 
-                 U FT_Done_FreeType 
-                 U FT_Get_BDF_Property 
-                 U FT_Get_Char_Index 
-                 U FT_Get_First_Char 
-                 U FT_Get_Glyph_Name 
-                 U FT_Get_Next_Char 
-                 U FT_Get_PS_Font_Info 
-                 U FT_Get_Postscript_Name 
-                 U FT_Get_Sfnt_Name 
-                 U FT_Get_Sfnt_Name_Count 
-                 U FT_Get_Sfnt_Table 
-                 U FT_Get_X11_Font_Format 
-                 U FT_Has_PS_Glyph_Names 
-                 U FT_Init_FreeType 
-                 U FT_Load_Glyph 
-                 U FT_Load_Sfnt_Table 
-                 U FT_New_Face 
-                 U FT_Select_Charmap 
-                 U FT_Select_Size 
-0000000000006d50 T FcAtomicCreate 
-0000000000007000 T FcAtomicDeleteNew 
-0000000000007040 T FcAtomicDestroy 
-0000000000006e10 T FcAtomicLock 
-0000000000006fc0 T FcAtomicNewFile 
-0000000000006fd0 T FcAtomicOrigFile 
-0000000000006fe0 T FcAtomicReplaceOrig 
-0000000000007010 T FcAtomicUnlock 
-00000000000070a0 T FcBlanksAdd 
-0000000000007050 T FcBlanksCreate 
-</code> 
-最后几行有十六进制地址的表示函数在这个文件中。前面有很多undefined symbol。但这个库仍然能用,因为它的依赖中有这些函数。我们注意到这些U的函数名为FT头,可能是freetype中的函数。所以用命令 
-<code>nm -D /usr/lib64/libfreetype.so</code> 
-肯定能找到以上函数。 
----- 
-再说一下版本号的问题。一般为 
- 
-主版本号.次版本号.补丁号 
- 
-主次相同,则接口完全兼容,函数的内部会有一些修正,不影响依赖该库的软件 
- 
-主相同,次增加,则一般会增加一些函数,兼容性一般没有问题,依赖该库的软件想用它的新特性则需要重新编译。比如A依赖B,B的1.1版有函数a,1.2版增加了函数b,以前安装A的时候configure检查出B中有a,没有b,则编译时代码中调用a的部分保留,调用b的则忽略,可能不编译相关部分(软件少了一个功能),也可能用A自带的实现(但如果A是python,B是C,则效率相差可想而知)。现在B更新至1.2版,A虽然没有更新,但重新编译则可利用b。 
- 
-主版本号增加,一般前后不兼容,更新需慎重。比如ffmpeg的2.x和3.x,SDL的1.x和2.x,有时候两者不能共存,比如前者;有时候可以,比如后者。通常情况下,为了方便开发者,共享库文件名.so后面的数字会增加以表示区别。如果共享库文件名前面的部分不同,则可以共存。比如ffmpeg,2.x版本有libavformat.so.56,3.x版本为libavformat.so.57,两者不兼容,详见http://ffmpeg.org/download.html。SDL因为1.x版使用极其广泛,即使开发者想重写,诞生了SDL2,但是为了不引起问题,共享库文件名都以libSDL2开头,和libSDL并存。 
-然而这些只是约定俗成,有时候总会出现bug。比如shadowsocks-libev的加密部分依赖libsodium,这个库只是更新了补丁号,但每次更新我都得重新编译shadowsocks-libev,真是蛋疼。不过毕竟是加密相关,我还是会重新编译一遍。 
zh/linuxfaq/version_compatibility.1560259759.txt.gz · 最后更改: 2019/06/11 22:29 由 まこと