GNU

今天是冬至，也是入冬以来感觉最冷的一天，毫不夸张的说：你一张嘴，牙就冻上了。上午LP在家收拾卫生，我继续用Scons改造现有的项目。下午出去理发，头发长长了后，似乎会造成思维迟钝^_^。 试验性的用Scons改造现有的project，过程中对Scons了解又多了一些。上篇文章对Scons的性能没有给出定论，经过对Scons的深入后，发现Scons在执行初始时的性能的确不够快，这是因为Scons启动后，会对全部SConstruct以及下面子目录中的SConscript进行分析，子目录越多Sconscript文件个数越多，性能也就越差。但是这种分析也有一个优点，就是能帮你提前发现你SConscript中的一些“语义”错误，比如如果你在编译两个基础库，一个叫add，一个叫sub，这个基础库源码分别分布在两个目录add和sub中，编译后将分别生成libadd.a和libsub.a的库文件，但是如果你马虎了，在编写SConscript时将target都写成了’add’或都写成了’sub’，则Scons会在执行gcc之前就帮你找出这个"语义"错误，提示如下： /export/home1/tony_bai/xxlib>scons -f SC*t scons: Reading SConscript files … scons: *** Multiple ways to build the same target were specified for: /export/home1/tony_bai/xxlib/lib/libsub.a (from [’/export/home1/tony_bai/xxlib/add/libsub.a’] and from [’libsub.a’]) File “/export/home1/tony_bai/xxlib/sub/SConscript”, line 3, in ...

发现或者说知道SCons是缘于Google的comp.lang.c group上的一则名为"Best Build Tool for large C projects “的帖子，帖子的作者列出了11条他认为"Best Build Tool"应该具备的特点，并欲找到这样的Build Tool。在该帖子的回复中，有人提到了Scons，说来惭愧，这是我第一次听说到有这样一个工具。一直在Unix下编写C程序，习惯了Make，也对Make的复杂度和较为陡峭的学习曲线有所了解，曾经尝试使用Autoconf和Automake，但是都因上手困难而放弃。自己心底也一直想找到一个更简单一些的但又不失功能的适合C的Build Tool，Scons是否能满足的需要的呢？好奇心驱使着我去发掘一下Scons。 ...

今天闲时写了一个Demo测试程序，目的：测试64位编译下使用mmap映射共享内存的能力。程序很简单，大致如下结构： #define MAP_SPACE_SIZE (4*1024*1024*1024) unsigned long int ms_sz = MAP_SPACE_SIZE; …. …. ptr = mmap( NULL, ms_sz, PROT_READ|PROT_WRITE,MAP_SHARED, fd, 0 ); ...

随着工程代码量的增加，往往完整的编译一次Proj消耗的时间可能足够你喝两杯咖啡了，我现在build一次我所在proj的代码需要5分多钟，这是很痛苦的，颇让人懊恼的。为了解决这个工作中的别扭事儿，我在网上搜寻了一番，找到了distcc这个分布式编译工具。 ...

近期公司实行新的绩效考核机制，我的考核目标中就有一项叫做：“成功使用新技术、框架、思路等至少3个”，呵呵，先不论绩效考核机制是否合理，既然已经这样了那就需要去适应。一直在做Network Application，早就知道ACE在业界中的名气，这回有理由找个时间好好挖掘一下ACE的思路，也为我的绩效目标增色啊^_^。 ...

程序员是追求完美的一族，即使是一般的程序员大多也都不想看到自己的程序中有甚至那么一点点的瑕疵。遇到任意一条编译器警告都坚决不放过。有人会说：我们可以使用比编译器更加严格的静态代码检查工具，如splint。这个建议也很不错。不过lint工具使用起来较繁琐，有时候还需要记住一些特定符号并插入到你自己的代码中才行，门槛较高，这也让很多人止步于此。那么我们就从此放弃么？不，如今的编译器做得都很好，它可以帮助我们的找到绝大多数可能出现问题的代码，前提是你要学会控制编译器去找到这些问题代码，而熟悉编译器的警告选项恰恰是体现控制力的好方法。当你可以自如控制编译器警告输出的时候，你就算是’入道’了，同时你对语言的理解也更进一步了。 ...

有一段时间没有写技术方面的东西了^_^。众所周知，GDB是Unix/Linux下调试程序的龙头老大，GDB功能强大，我们在平时多使用其一些最基本的功能，而且一般调试的都是单进程的程序。最近一个项目中的问题让我接触如何使用GDB调试多进程程序，更确切的是说调试调用fork的多进程程序。 使用GDB最好的文档就是其名为’Debugging with GDB‘的参考手册。手册中有一小章节提到了如何调试多进程程序。一般情况下，如果被gdb调试的程序中调用fork派生出一个新的子进程，这时gdb调试的仍然还是父进程，其子进程的执行不被理会。如果之前你在子进程的执行routine上设置了断点，那么当子进程执行到那个断点时，子进程会因为收到一个SIGTRAP信号而自行终止，除非你在子进程中拦截了该信号。 ...

最近看了Eric S. Raymond的被称为开源文化圣典的’Cathedral and Bazaar’(大教堂与市集)以及他的另外一篇文章’How To Become A Hacker’，必须承认的是我不能够完全理解其中的内容，因为没有体验，或者说我还不够资格对Hacker Culture高谈阔论，所以这里仅作部分摘要，并说说自己第一时间的感受，望日后能温故知新。 ...

工作这么长时间，一直在C语言这一层面上钻研和打拼，日积月累，很多关于C的疑惑在书本和资料中都难以找到答案。程序员是追求完美的一个种群，其头脑中哪怕是存在一点点的思维黑洞都会让其坐卧不宁。不久前在itput论坛上偶得《Computer Systems A Programmer’s Perspective》（以下称CSAPP）这本经典好书，遂连夜拜读以求解惑。虽说书中没有能正面的回答我的一些疑惑，但是它却为我指明了一条通向“无惑”之路 — 这就是打开汇编之门。 ...

Tony : Hey Alex, How are you doing? Alex : 不怎么样。(显得很消沉的样子) Tony : Oh , Really ? What is the matter? Alex : 事情是这样的。最近有一个Unix下的C++项目要求我独自完成，以前都是跟着别人做，现在让自己独立完成，还真是不知道该怎么办，就连一个最简单的项目的Makefile都搞不定。昨晚看了一晚上资料也没有什么头绪。唉！！ Tony : 别急，我曾经有一段时间研究过一些关于Makefile的东西，也许能帮得上忙，来，我们一起来设计这个项目的Makefile。 Alex : So it is a deal。(一言为定) Tony : 我们现在就开始吧，给我拿把椅子过来。 ...