开了一个下午的技术交流会，回到办公室时离下班时间已经不远，天气预报说今晚有暴雪，外面阴沉的天气似乎也证实了这一点。这时一个同事遇到了一个软件包编译的问题，一时无法解决，向我求助。

这是一个libmemcached的编译问题，我们用的是libmemcached 0.34版本，我的同事在PC Solaris上执行libmemcached的configure脚本时遇到如下错，Configure脚本提示：

checking for pthread-config… no
configure: error: could not find libpthread

但经过确认系统中明明在/usr/lib下有pthread相关库的存在：
Tony Bai-[~/libmemcached-0.34]526:>ll /usr/lib|grep pthread
lrwxrwxrwx   1 root     root          26 2009   9月 10 llib-lpthread.ln -> ../../lib/llib-lpthread.ln
lrwxrwxrwx   1 root     root          23 2009   9月 10 llib-lpthread -> ../../lib/llib-lpthread
lrwxrwxrwx   1 root     root          25 2009   9月 10 libpthread.so.1 -> ../../lib/libpthread.so.1*
lrwxrwxrwx   1 root     root          25 2009   9月 10 libpthread.so -> ../../lib/libpthread.so.1*

又确认了一下用户的环境变量设置，LD_LIBRARY_PATH也包含了这些库的目录。

经验告诉我，这个错误是假象，向上翻Configure的输出结果，的确发现些奇怪的Check结果，如下：

checking for ANSI C header files… no
checking for sys/types.h… no
checking for sys/stat.h… no
checking for stdlib.h… no
checking for string.h… no
checking for memory.h… no
checking for strings.h… no
checking for inttypes.h… no
checking for stdint.h… no
checking for unistd.h… no

第一感觉，这怎么可能呢？这些标准C库头文件居然都Check失败了！在网上用“checking for ANSI C header files… no”搜了一下，也没有找到很好的答案。

我对Configure了解也不多，但是还是让我发现了config.log这根救命稻草。config.log这个文件详细地记录了Configure的每一步校验的执行内容和结果，其中对于标准C头文件的Check是这样做的：

configure:4827: checking for ANSI C header files
configure:4857: gcc -c -g -O2 -m64  conftest.c >&5
conftest.c:1: sorry, unimplemented: 64-bit mode not compiled in
configure:4864: $? = 1
configure: failed program was:
| /* confdefs.h.  */
| #define PACKAGE_NAME "libmemcached"
| #define PACKAGE_TARNAME "libmemcached"
| #define PACKAGE_VERSION "0.34"
| #define PACKAGE_STRING "libmemcached 0.34"
| #define PACKAGE_BUGREPORT "http://tangent.org/552/libmemcached.html"
| /* end confdefs.h.  */
| #include
| #include
| #include
| #include
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:4995: result: no

再往下看，检测sys/types.h等标准库头文件的错误都是：
conftest.c:1: sorry, unimplemented: 64-bit mode not compiled in
configure:5047: $? = 1

看来并非是系统没有包含标准头文件，而是Configure采用了64-bit编译的方法去测试头文件存在的时候出错。随意创建一个testm64.c的源文件，输入:

/* testm64.c */
int main() {
    ;
    return 0;
}
用gcc -g -m64 testm64.c执行编译，得到与之前相同的错误结果：
testm64.c:1: sorry, unimplemented: 64-bit mode not compiled in

查看Gcc版本，发现是3.4.6，突然恍然大悟，这不是之前发现在Solaris 10 for x86上Gcc 64位编译的一个问题吗，在Solaris 10 for x86上如果要进行64位编译，要使用/usr/sfw/bin下的gcc 3.4.3版本，不能用3.4.6版本。

除了更换Gcc之外，如果你想编译32位版本的话，还可以这样来做：修改Configure脚本，打开Configure，将-m64字样全部删除。这样Configure后编译libmemcached就一切顺利了。

以上关于Configure脚本问题的解决方法，有一定的通用性，因此记之。

都说汇编不易学习和使用，的确不假。自己自大学以来也曾多次尝试学习汇编，甚至大学时还有相应课时，但是自己对汇编依旧是浅尝辄止。工作后也少有使用，对汇编的认识也就停留在基础层面。汇编的学习与对计算机系统的理解是密不可分的。工作这些年也算是一直浸淫于系统层面，经过多本底层相关书籍的教诲以及工作中的实践，对计算机系统的理解就自然而然加深了。昨天下载了一本名为：“Professional Assembly Language(中文名：汇编语言程序设计)” 的电子书，目的是想了解一下C内联汇编（Inline Assmebly）。花了半个小时读后，居然感觉轻松自如，和自己大脑中的知识融会贯通起来。发现这本书在卓越网还有“剩本”，也就抓紧买了下来，下周到货。

本书使用linux和AT&T汇编语法，正合我的胃口。以下是根据书中例子改出来的一段汇编版HelloWorld.s：

# HelloWorld.s
# as -o HelloWorld.o HelloWorld.s
# ld -o HelloWorld HelloWorld.o

.section .data
output:
        .ascii "hello world\n"

.section .text
.globl _start
_start:
        nop
        movl $output, %ecx
        movl $4, %eax   # the index of sys call 'write'
        movl $1, %ebx   # file descriptor
        movl $12, %edx  # length of the string
        int $0×80

        movl $1, %eax   # the index of sys call 'exit'
        movl $0, %ebx
        int $0×80

在调试上面代码时有两个注意事项要考虑：
1、调用write时，%edx务必赋值，否则将无法正确输出；
2、在Ubuntu 9.04下，如果结尾不调用exit，执行程序后会有'段错误'，目前依然不得其解，通过GDB调测后猜测是未作收尾处理，处理器继续取EIP所指地址的指令内容，执行出错。

将这段代码拿到Solaris10 for x86上执行，无法输出“hello world”，并伴有'段错误'，目前尚不得其解。

让HelloWorld.s作为再次尝试熟悉汇编的一个起点吧^_^。