|
机子比较烂,一直mask gcc 在 4.4.5,一个月前把ACCEPT_KEYWORDS改成了"~x86", dev-libs/gmp自动到5.0.1, portage提示说检测到gcc-4.4.5依赖旧(低版本)的libgmp,运行revdep-rebuid --library 来rebuild一下gcc,成功后就把旧的libgmp给删除了,一切都像设计好的那样轻松。
今天又想从~x86退回到x86上来,emerge --sync以后gcc还是4.4.5(masked),不升也不降,dev-libs/gmp会降到4.3.2(当时没注意到它),emerge完gmp-4.3.2以后gcc**了,翻了好几个包的build.log, 有的提示说“不能创建可执行文件”,有的说“没有可用的C编译器”,有一个包提示说“没有找到libgmp.so.10”。
这个时候知道是现在正在用的gcc在最初更换到"~x86"的时候已经rebuild为依赖libgmp.so.10, 而dev-libs/gmp现在降级到4.3.2,emerge完成后portage并没有像往上升级的时候提示说有旧(低版本)的库依赖一样提示说有较新(高版本)的库依赖,请revdep-rebuild到低版本的库上。portage直接删除了高版本的libgmp-1.10,这样就导致gcc没法用了,就会出现上边的那些错误。
gcc不能用是件很尴尬的事,当时差点就重新安装gentoo了,但是这个系统已经快两年没格了,很不舍得。于是就想了一个脏办法,直接软链接/usr/lib/libgmp.so.10到/usr/lib/libgmp.so.3(gmp-4.3.2安装的库),结果运气不错,gcc 又能用了。然后又将dev-libs/gmp添加了"~x86" keywords, 先把它单独升级到了5.0.1。`equery f =dev-libs/gmp-5.0.1`会发现它安装了libgmp.so-10.0.1,连同一个软链至此的libgmp.so.10。因为刚从dev-libs/gmp-4.3.2升级上来,所以portage又提示说请`revdep-rebuild --library /usr/lib/libgmp.so.3'。这种情况下运行这个命令你会发现portage不会rebuild gcc,因为这时的gcc已经在最初的时候rebuild到dev-libs/gmp-5.0.1上了。由此看来revdep-rebuild检测反向依赖不仅是靠遗留的库文件,还有些内部的什么手段(这个我就说不好了 哈哈)。
不知道为什么portage在库降级的时候不会像升级的时候那样先保留旧的(时间上),然后提示revdep-rebuild呢?。难道或者是提示了我没注意到?也懒得去翻了,都过去了
还得出了一点,当很多包同时emerge出错的情况下,要多看几个不同的build.log,因为不同的包给出的出错信息不一样,这样更容易得到准确的出错信息。
Note that, 当运行某个软件提示说某个库版本号不符合的时候,就试一下软链这个“脏”办法,虽然不优雅,但有时能救急。
对了,又想到一点关于从~x86退回到x86的经验,就是要同时给openrc和baselayout加上"~x86" keyword, 不然就有些悲剧了……迁移到openrc的同学都懂的。 |
|