关于WSL1中libgc的某些故障导致Wrong __data_start_end_pair问题的描述和后续解决方案

关于WSL1中libgc的某些故障导致Wrong __data_start/_end pair问题的描述和后续解决方案

启动w3m时遇到问题w3m Wrong __data_start/_end pair问题

大多数（包括中文社区和英文社区）给出的分析是“这个问题是WSL1导致的，升级到WSL2就解决啦”

我信你个鬼，WSL2的坑爹是远近闻名的

查询之后，一个网页给出了解决方案:WSL Ubuntu guile命令报错Wrong __data_start/_end pair及guile-gi等相关编译错误的解决方法

溯源其中提到的libsndfile fails to build on Ubuntu 20.04 with WSL网页，其中给出的解决方案是

1
2
3
4
5
6
7
8
9
10
11

sudo dpkg -r --force-depends "libgc1c2" # remove old libgc

git clone git://github.com/ivmai/bdwgc.git

cd bdwgc

./autogen.sh

./configure --prefix=/usr && make -j # its default is the wrong directory? huh?`

sudo make install

（个人认为此顺序不妥，鉴于网络的实际情况，以及开发环境不一定配置完毕，应该先执行git clone等命令，直到确认./autogen.sh执行无误之后，再行sudo dpkg -r --force--depends等卸载命令，最后再执行./configure和sudo make install）

在按照这个办法执行完毕之后，虽然w3m可以正常运行（表示libgc可以被正常调用），但是dpkg表示出现了依赖未解决问题。

显然依赖未解决，因为之前已经强制dpkg remove了依赖关系。

此时如果按照推荐方式，执行sudo apt --fix-broken install，将会解决依赖的问题，但是同时也会重新安装旧版本的libgc，也即什么问题都没解决。

这时候有两种解决方案，第一种是手动修改/var/lib/dpkg/status文件，这种方法多少令人有些抗拒。

另一个办法是伪装系统内的库，这需要考虑linux的这套库调用系统是如何运作的

在/usr/lib/x86_64-linux-gnu/内有目前不适应实际情况的过时libgc.so.1和libgc.so.1.3.2两个库

而根据上述解决方案，使用--prefix=/usr进行configure并进行make install之后，会在/usr/lib下安装libgc.so.1.5.0库

经过检查，/usr/lib/x86_64-linux-gnu/内的libgc.so.1实际上是一个软链接，因此将其链接的目标进行更改也许是一个可行的办法

因此最终的解决方案是，在/usr/lib/x86_64-linux-gnu/进行了如下操作：

1
2
3
4
5
6
7

sudo mv libgc.so.1 libgc.so.1.bak

sudo mv libgc.so.1.3.2 libgc.so.1.3.2.bak

sudo ln -sf /usr/lib/libgc.so.1.5.0 libgc.so.1

sudo ln -sf /usr/lib/libgc.so.1.5.0 libgc.so.1.3.2

如此，一番指鹿为马的操作就完成了

（也许这么生草的办法哪天突然就炸了也说不定

（所以才要记下来防止翻车

Knighthana 2021/8/29 4:05 (UTC+8)

更新：

刚刚在网上冲浪，发现了一篇文章，提供了修改包管理器数据库的几个方案：

史上最硬核的 Linux 依赖问题解决方案 | 技术

Knighthana 2021/8/29 4:15 (UTC+8)

这篇被标记为草台教程，请谨慎参考食用