在64位ubuntu系统上运行mudos v22pre11

几年前自己架过一个mud偶尔玩玩，mudos是v22pre11版本的，运行在32位的redhat上；前几天想跑起来耍耍，但目前都是64的ubuntu系统了，尝试将以便保存的mudos程序在ubuntu上运行，直接就出错退出了，segment fault。

把源码拿到ubuntu系统上重新编译，编出来的文件，也是一运行就直接退出了。

尝试安装redhat的虚拟机，是可以正常运行的，不过虚拟机占资源多，而且效率也低，不是最佳方案。抽了点时间尝试解决这个问题，发现导致退出的问题是在debug_message函数，输出调试信息的时候，debug_message支持可变参数，所以采用了va_start / va_arg / va_end三段论处理，但因为需要同时输出到console和log文件，所以vfprintf调用了两次；老的库函数是没有问题的，新版本的库函数的vfprintf调用是有副作用的，会破坏va_list，下次再对这个va_list调用的时候就会出错了；解决方法也很简单，用vsprintf输出到临时buffer，送给两个文件，就没有问题了。

解决了这个问题mudos是可以起来了，但是mudlib还是不能用，用户可以连上，logon的时候就直接报错后关闭网络连接；尝试解决发现问题比较复杂，因为mudos是编译运行的，而mudlib是解释执行的，调试起来也非常不方便，而且即便解决了当前问题可能还会有更多的问题，代码比较多，也不想花太多精力在这上面。

看来必须要考虑更好的方案了，尝试了一下v22.2b14版本的mudos，也是各种问题；据说fluffos对64位系统的支持比较好，但是即便搞定了mudos，还可能存在mudlib的兼容性问题，整体工作量不好把握；看起来换mudos并不是非常有把握的方案。

想了一下，出现问题有两个可能的因素，一是32位系统和64位系统的兼容性问题，二是libc等函数库的版本兼容性问题，因为mudos采用动态编译，在ubuntu上执行时最终会调用到系统库对应的so文件，所以针对老版本库的写法在新版本下就可能出问题，比如上面提到的debug_message对可变参数的处理导致的问题；

这样解决方案就出来了，就是采用静态编译。到redhat虚拟机上，找到源码目录，修改GNUmakefile文件，找到CFLAGS=，改成CFLAGS=-static，指定静态编译，然后重新make，把得到的mudos拿到ubuntu上，就可以正常运行了。

经测试静态编译的mudos v22pre11可以在64位ubuntu上稳定运行，和32位redhat系统的表现并无差异。