昨天一度以为那个模块编好了就一劳永逸了，结果今天早上到了之后又悲剧的发现还有另外一个东西要编译，sigh，为了工作正常展开，为了不倒退到ubuntu时代，只能上了。
首先遇到的问题是一个文件中用了SOCK_NONBLOCKING，翻了一下socket的manual, 发现果然没有（当时狗眼瞎了，没有看到赫然印着的BSD system calls manual）, 还在傻乎乎的想，是不是我g++版本的问题，导致没有这个东东呢。。。捂脸。。。
正如网页gnu c library上说的那样，unix-like 系列的操作系统都需要一个定义了系统调用和其他如open，malloc之类基础设施的c语言库，在mac里，被放在了/usr/lib/system中。回忆一下系统库和标准c库之间的不同，省的再次头昏脑涨。
至于为什么没有SOCK_NONBLOCK，跟内核有关，我大mac党躺枪....最后删了一些代码了事(我这边用不到那些)
随后遇到的问题是mach-o, but wrong architecture，是模块编译成功后dlopen该模块产生了问题，解决这个问题饶了一些弯子。
首先隆重介绍工具lipo, 这个是用来生成或者操作universal文件的，所谓universal文件就是multi-architecture文件,于是。。。我用它来查看架构。。。经过检查发现python的arch和要用库的都是x86_64，于是开始检查python, defaults read com.apple.versioner.python 能够检查当前版本python的默认架构, 发现是坑爹的
{
"Prefer-32-Bit" = 1;
"Prefer-64-Bit" = 1;
}
难怪会有wrong architecture的问题，改之，然后就能正确的运行了。顺手查了一下dlopen(), 里面提到
dlopen() can load dynamic libraries and bundles.
这就跟上一篇文章里面的说法不太一致了，这个事儿还是留时间做做实验吧.
还有一个遗留问题，晚上查吧