<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>GNU on Tony Bai</title><link>https://tonybai.com/tags/gnu/</link><description>Recent content in GNU on Tony Bai</description><generator>Hugo</generator><language>zh-cn</language><copyright>2004-2026 Tony Bai. 版权所有.</copyright><lastBuildDate>Thu, 08 May 2025 00:00:00 +0800</lastBuildDate><atom:link href="https://tonybai.com/tags/gnu/index.xml" rel="self" type="application/rss+xml"/><item><title>Go 1.25链接器提速、执行文件瘦身：DWARF 5调试信息格式升级终落地</title><link>https://tonybai.com/2025/05/08/go-dwarf5/</link><pubDate>Thu, 08 May 2025 00:00:00 +0800</pubDate><guid>https://tonybai.com/2025/05/08/go-dwarf5/</guid><description>Go 1.25链接器提速、执行文件瘦身：DWARF 5调试信息格式升级终落地 - Tony Bai =============== Tony Bai 一个程序员的心路历程 * Google Go语言编码风格规范 * Google Go语言编码风格规范：指南篇 * Google Go语言编码风格规范：决定篇 * Google Go语言编码风格规范：最佳实践篇 * Go语言第一课FAQ * Go语言进...</description></item><item><title>Go开发命令行程序指南</title><link>https://tonybai.com/2023/03/25/the-guide-of-developing-cli-program-in-go/</link><pubDate>Sat, 25 Mar 2023 00:00:00 +0800</pubDate><guid>https://tonybai.com/2023/03/25/the-guide-of-developing-cli-program-in-go/</guid><description>&amp;gt; 注：上面篇首配图的底图由百度文心一格生成。 本文永久链接 – https://tonybai.com/2023/03/25/the-guide-of-developing-cli-program-in-go 近期在Twitter上看到一个名为“Command Line Interface Guidelines”的站点，这个站点汇聚了帮助大家编写出更好命令行程序的哲学与指南。这份指南基于传统的U...</description></item><item><title>Go 1.15中值得关注的几个变化</title><link>https://tonybai.com/2020/10/11/some-changes-in-go-1-15/</link><pubDate>Sun, 11 Oct 2020 00:00:00 +0800</pubDate><guid>https://tonybai.com/2020/10/11/some-changes-in-go-1-15/</guid><description>Go 1.15版本在8月12日就正式发布了，给我的感觉就是发布的挺痛快^\_^。这种感觉来自与之前版本发布时间的对比：Go 1.13版本发布于当年的9月4日，更早的Go 1.11版本发布于当年的8月25日。 不过这个时间恰与我家二宝出生和老婆月子时期有重叠，每天照顾孩子团团转的我实在抽不出时间研究Go 1.15的变化:(。如今，我逐渐从照顾二宝的工作中脱离出来^\_^，于是“Go x.xx版本值得...</description></item><item><title>Recommended C Style and Coding Standards中文版全文</title><link>https://tonybai.com/2013/11/26/the-full-text-of-recommended-c-style-and-coding-standards/</link><pubDate>Tue, 26 Nov 2013 00:00:00 +0800</pubDate><guid>https://tonybai.com/2013/11/26/the-full-text-of-recommended-c-style-and-coding-standards/</guid><description>今天无意中打开了托管在Google Code上的“Recommended C Style and Coding Standards”翻译项目，忽感觉通过目录链接的方式查看译文缺少整体感，于是花了点时间将译文全文以single page的形式贴在博客里面，方便大家查看，也算是对该翻译内容的一个备份吧。 **C语言编码风格和标准** **0\. 摘要** 本文翻译自《Recommended C Sty...</description></item><item><title>buildc 0.3.1版本发布</title><link>https://tonybai.com/2013/07/15/buildc-0-3-1-release/</link><pubDate>Mon, 15 Jul 2013 00:00:00 +0800</pubDate><guid>https://tonybai.com/2013/07/15/buildc-0-3-1-release/</guid><description>随着buildc在内部应用的深入，buildc逐渐进入了以内部需求和问题为主要驱动力的演化模式。我们内部的C应用多是后端服务类应用，个人 觉得具有一定代表性。buildc最初就是为了针对这类C应用而设计的。因此我们内部的需求和问题应该也同样具有一定代表性，而这种演化模式在一 段时间范围内还是有意义的。 buildc 0.3.1版本修正了上一版本的若干bug，并增加了两个新功能。 **\* 提高容错...</description></item><item><title>跨过BUG查找的"最后一公里"</title><link>https://tonybai.com/2013/06/18/walk-through-the-last-mile-of-bugfix/</link><pubDate>Tue, 18 Jun 2013 00:00:00 +0800</pubDate><guid>https://tonybai.com/2013/06/18/walk-through-the-last-mile-of-bugfix/</guid><description>_如果你看到一个C程序员在通宵熬夜神情紧张地对着电脑敲代码或阅读代码，多数只有两种可能：一是为了赶进度；二就是查找内存Bug。_                                                                                                                               _— 个人感悟_ ...</description></item><item><title>再谈C语言位域</title><link>https://tonybai.com/2013/05/21/talk-about-bitfield-in-c-again/</link><pubDate>Tue, 21 May 2013 00:00:00 +0800</pubDate><guid>https://tonybai.com/2013/05/21/talk-about-bitfield-in-c-again/</guid><description>我在日常工作中使用C语言%E2%80%8E)中的位域(bit field)的场景甚少，原因大致有二： \* 一直从事于服务器后端应用的开发，现在的服务器的内存容量已经达到了数十G的水平，我们一般不需要为节省几个字节而使用内存布局更加紧凑的位域。 \* 结构体中位域的实现是平台相关或Compiler相关的，移植性较差，我们不会贸然地给自己造“坑”的。 不过近期Linux技术内核社区（www.linu...</description></item><item><title>libiconv库链接问题一则</title><link>https://tonybai.com/2013/04/25/a-libiconv-linkage-problem/</link><pubDate>Thu, 25 Apr 2013 00:00:00 +0800</pubDate><guid>https://tonybai.com/2013/04/25/a-libiconv-linkage-problem/</guid><description>与在Solaris系统上不同，Linux的libc库中包含了libiconv库中函数的定义，因此在Linux上使用libiconv库相关函数，编译时是不需要显式-liconv的。但最近我的一位同事在某redhat enterprise server 5.6机器上编译程序时却遇到了找不到iconv库函数符号的链接问题，到底是怎样一回事呢？这里分享一下问题查找过程。 **一、现场重现** 这里借用一下...</description></item><item><title>玩转top</title><link>https://tonybai.com/2013/03/02/deep-into-top/</link><pubDate>Sat, 02 Mar 2013 00:00:00 +0800</pubDate><guid>https://tonybai.com/2013/03/02/deep-into-top/</guid><description>相信很多人和我一样，top是自己日常使用最多的linux资源查看工具。不过仅限于一些简单的日常场景罢了：敲入top命令，看看哪些进程占用 CPU较多，然后对这些CPU占用较多的进程逐一处理一下。显然这样使用top有些大才小用了。 以前在监控工具使用方面总是浅尝辙止，并未做过多深入研究。近来愈来愈觉得有必要针对几种常用工具好好学习一下了。而top便首当其冲。top是一款 以查看进程(task)信息为...</description></item><item><title>Go defer的C实现</title><link>https://tonybai.com/2013/02/03/implement-go-defer-in-c/</link><pubDate>Sun, 03 Feb 2013 00:00:00 +0800</pubDate><guid>https://tonybai.com/2013/02/03/implement-go-defer-in-c/</guid><description>Go语言中引入了一个新的关键字defer，个人认为这个语法关键字让异常处理也变得得心应手许多，对改善代码的可读性和可维护性大有裨益，是典型的语法棒棒糖^\_^。 像下面这种代码（伪代码）： void foo() {     apply resource1; retv = action1;     if not success         release resource1 apply reso...</description></item><item><title>将Unity换成Gnome3</title><link>https://tonybai.com/2012/12/06/replace-unity-with-gnome3/</link><pubDate>Thu, 06 Dec 2012 00:00:00 +0800</pubDate><guid>https://tonybai.com/2012/12/06/replace-unity-with-gnome3/</guid><description>Ubuntu 12.04已经体验一天多了，Unity还是用的不大习惯，左侧的程序启动栏感觉还是别扭，以前用windows的时候就不喜欢将任务栏放在左侧或右侧； 应用窗口的菜单栏融合到桌面顶端也没给我太多惊喜；总而言之，给自己找几个换回Gome的理由还是很容易的^\_^。况且Gnome也发生了巨变， 由传统的Gnome2更新到了全新的Gnome3，正好我也想体验一下Gnome3，于是继续折腾。 Ub...</description></item><item><title>做正确的事要趁早</title><link>https://tonybai.com/2012/08/02/do-right-things-early/</link><pubDate>Thu, 02 Aug 2012 00:00:00 +0800</pubDate><guid>https://tonybai.com/2012/08/02/do-right-things-early/</guid><description>最近闲暇时间在策划实施两件事儿：一是产品的自动化回归测试；二是尝试在项目中使用一些静态代码语义分析工具。我觉得这两件事是应该做的正确的事，对提升产品质量，提前发现产品中潜在的缺陷都大有裨益。但在做的过程中才感觉到：现在做有些晚，正确的事要趁早做。 去年自动化测试组发布了自动化测试框架的第一个版本，我们的产品参加了试点。但经过自动化测试组大半年的投入，效果十分有限，根本没有达到我的预期。最主 要的问...</description></item><item><title>buildc 0.1.9版本发布</title><link>https://tonybai.com/2012/07/19/buildc-0-1-9-release/</link><pubDate>Thu, 19 Jul 2012 00:00:00 +0800</pubDate><guid>https://tonybai.com/2012/07/19/buildc-0-1-9-release/</guid><description>随着buildc使用的深入，越来越多的新需求暴露了出来。为了满足这些需求，我们组的小兄弟又对buildc进行了一些改造，这些变化如下： 1、支持将多个子工程打包到一个安装包中 最初buildc的设计思想是为每个子工程单独制作安装包，这样具有很强的灵活性。但在对现有N个工程进行构建脚本改造的过程中发现，有些工程间存在严重 依赖，比如工程A是一个业务级公共库工程，工程B和工程C都依赖工程A构建后生成的...</description></item><item><title>buildc 0.1.8版本发布</title><link>https://tonybai.com/2012/07/02/buildc-0-1-8-release/</link><pubDate>Mon, 02 Jul 2012 00:00:00 +0800</pubDate><guid>https://tonybai.com/2012/07/02/buildc-0-1-8-release/</guid><description>buildc这个小工具逐渐在项目组内部扩大了使用范围，还有一名专门的同事负责为每个项目制作安装包工程，这样也可以在使用中发现buildc的问题。 本次buildc 0.1.8的相关修正以及新增的feature就是我的这位年轻同事一手操刀完成的，他也是一个python新手，同样也是边翻手册边进行编码的。这次改动主要集中在templates目录下的几个文件，这里的文件多为因工程的不同而异的。 这次bu...</description></item><item><title>buildc 0.1.7版本发布</title><link>https://tonybai.com/2012/04/19/buildc-0-1-7-release/</link><pubDate>Thu, 19 Apr 2012 00:00:00 +0800</pubDate><guid>https://tonybai.com/2012/04/19/buildc-0-1-7-release/</guid><description>最近针对buildc又有了一些新想法，于是今天上午又对buildc进行了多处修改，并相继发布了0.1.6版本和0.1.7版本。 \* 对buildc cache upgrade的实现进行了修改。 在执行全量更新本地cache前，先对本地cache的情况进行一些检查，并判断是否与当前.buildc.rc中的配置相符。如果两者是一致的，那么只进行update操作；否则则执行真正的upgrade(rem...</description></item><item><title>buildc 0.1.5版本发布</title><link>https://tonybai.com/2012/04/13/buildc-0-1-5-release/</link><pubDate>Fri, 13 Apr 2012 00:00:00 +0800</pubDate><guid>https://tonybai.com/2012/04/13/buildc-0-1-5-release/</guid><description>这两天对buildc的改动比较频繁，今天又修正了一些问题，也增加了一些小功能。主要包括这么几点： 1、在Make.rules.in中增加了STATIC\_LIBS和DYNAMIC\_LIBS 项目源代码和项目中单元测试代码使用同一个Make.rules，也此编译时也就共享同一个LIBS变量。对于静态共享库还好说，但对于动态共享库，诸如Oracle的instantclient库，单元测试代码中即使没...</description></item><item><title>buildc 0.1.4版本发布</title><link>https://tonybai.com/2012/04/12/buildc-0-1-4-release/</link><pubDate>Thu, 12 Apr 2012 00:00:00 +0800</pubDate><guid>https://tonybai.com/2012/04/12/buildc-0-1-4-release/</guid><description>年后buildc开始逐渐在产品线的项目里应用了，随之而来的是大家反馈的各种意见和bug。尤其是bug，我都会很认真地应对，也会及时发布相应的版本修复这些bug。buildc 0.1.4版本就是一个bugfix版本，其修复的bug源于今天上午的一次持续集成的失败。 上午收到Jenkins发送的一个&amp;#34;build failed&amp;#34;的mail，一个安装包项目的CI job执行失败了，于是到Jenkins w...</description></item><item><title>关于编译阶段符号多重定义的问题</title><link>https://tonybai.com/2012/04/11/multiple-definitions-of-the-compiling-phase/</link><pubDate>Wed, 11 Apr 2012 00:00:00 +0800</pubDate><guid>https://tonybai.com/2012/04/11/multiple-definitions-of-the-compiling-phase/</guid><description>印象中关于编译以及链接的问题早已是老生常谈了。但今天又遇到了一个这样的问题，这里还总想提及一下下^\_^。 这次要说的问题依旧发生在使用lcut进行单元测试的过程中。一位同事在编译使用了mock函数的测试用例代码时出现了&amp;#34;multiple definition of &amp;#39;xxx&amp;#39;“的错误。这里简单模拟其场景如下： /\* testall.c \*/ /\* mock lib function \*/...</description></item><item><title>lcut 0.3.0版本发布</title><link>https://tonybai.com/2012/04/10/lcut-0-3-0-release/</link><pubDate>Tue, 10 Apr 2012 00:00:00 +0800</pubDate><guid>https://tonybai.com/2012/04/10/lcut-0-3-0-release/</guid><description>lcut单元测试框架在我的项目中应用已经有一段时间了，项目组的同事对lcut的使用也是越来越熟悉，这不今天一位同事还提出了一个新需求，需求大致是这样的。 在实际项目中，经常遇到这类情况： int bar(…) { int ret; ret = foo(…); /\* assert ret \*/ … ret = foo(…); /\* assert ret \*/ … ret = foo(…); ...</description></item><item><title>如何加入Linux内核开发社区(7)</title><link>https://tonybai.com/2012/04/09/how-to-participate-linux-community-section-7/</link><pubDate>Mon, 09 Apr 2012 00:00:00 +0800</pubDate><guid>https://tonybai.com/2012/04/09/how-to-participate-linux-community-section-7/</guid><description>本文翻译自The Linux Foundation的《How to Participate in the Linux Community》(基于2012-03-21最新版本)，原作者为Jonathan Corbet(corbet@lwn.net)。 下面是该文章第七章、第八章以及第九章节的中译文。 **7、高级主题** 但愿此时此刻，你已经理解了内核开发过程是如何进行的。但仍然还有很多东西要学习！...</description></item><item><title>如何加入Linux内核开发社区(5)</title><link>https://tonybai.com/2012/04/05/how-to-participate-linux-community-section-5/</link><pubDate>Thu, 05 Apr 2012 00:00:00 +0800</pubDate><guid>https://tonybai.com/2012/04/05/how-to-participate-linux-community-section-5/</guid><description>本文翻译自The Linux Foundation的《How to Participate in the Linux Community》(基于2012-03-21最新版本)，原作者为Jonathan Corbet(corbet@lwn.net)。 下面是该文章第五章节的中译文。 **5、发布补丁** 迟早有一天你的工作将提交到开发社区进行评审，并最终合入内核主线。不出所料，内核开发社区在发布补丁...</description></item><item><title>如何加入Linux内核开发社区(6)</title><link>https://tonybai.com/2012/04/05/how-to-participate-linux-community-section-6/</link><pubDate>Thu, 05 Apr 2012 00:00:00 +0800</pubDate><guid>https://tonybai.com/2012/04/05/how-to-participate-linux-community-section-6/</guid><description>本文翻译自The Linux Foundation的《How to Participate in the Linux Community》(基于2012-03-21最新版本)，原作者为Jonathan Corbet(corbet@lwn.net)。 下面是该文章第六章节的中译文。 **6、将补丁工作进行到底** 此时此刻，你已经遵循了这里到目前为止给出的所有指导原则，并且由于你自己的工程技能，你已...</description></item><item><title>如何加入Linux内核开发社区(4)</title><link>https://tonybai.com/2012/03/31/how-to-participate-linux-community-section-4/</link><pubDate>Sat, 31 Mar 2012 00:00:00 +0800</pubDate><guid>https://tonybai.com/2012/03/31/how-to-participate-linux-community-section-4/</guid><description>本文翻译自The Linux Foundation的《How to Participate in the Linux Community》(基于2012-03-21最新版本)，原作者为Jonathan Corbet(corbet@lwn.net)。 下面是该文章第四章节的中译文。 **4、正确地编写代码** 关于那个可靠的面向社区的设计过程我们已经说的够多了，任何内核开发项目的证据都是最终的代码。...</description></item><item><title>如何加入Linux内核开发社区(3)</title><link>https://tonybai.com/2012/03/29/how-to-participate-linux-community-section-3/</link><pubDate>Thu, 29 Mar 2012 00:00:00 +0800</pubDate><guid>https://tonybai.com/2012/03/29/how-to-participate-linux-community-section-3/</guid><description>本文翻译自The Linux Foundation的《How to Participate in the Linux Community》(基于2012-03-21最新版本)，原作者为Jonathan Corbet(corbet@lwn.net)。 下面是该文章第三章节的中译文。 **3、早期规划** 当考虑一个Linux内核开发项目时，人们可能很想尽快投入并开始编码。但和任何重要的项目一样，推动...</description></item><item><title>如何加入Linux内核开发社区(2)</title><link>https://tonybai.com/2012/03/28/how-to-participate-linux-community-section-2/</link><pubDate>Wed, 28 Mar 2012 00:00:00 +0800</pubDate><guid>https://tonybai.com/2012/03/28/how-to-participate-linux-community-section-2/</guid><description>本文翻译自The Linux Foundation的《How to Participate in the Linux Community》(基于2012-03-21最新版本)，原作者为Jonathan Corbet(corbet@lwn.net)。下面是该文章第二章节的中译文。 **2、内核开发过程是如何进行的** 在20世纪90年代初，当时的Linux内核开发是一件非常松散的事情，涉及的用户和开...</description></item><item><title>如何加入Linux内核开发社区(1)</title><link>https://tonybai.com/2012/03/27/how-to-participate-linux-community-section-1/</link><pubDate>Tue, 27 Mar 2012 00:00:00 +0800</pubDate><guid>https://tonybai.com/2012/03/27/how-to-participate-linux-community-section-1/</guid><description>本文翻译自The Linux Foundation的《How to Participate in the Linux Community》(基于2012-03-21最新版本)，原作者为Jonathan Corbet(corbet@lwn.net)。下面是该文章第一章节的中译文。 **1、内核开发过程指南** 本文旨在帮助那些在参与开发社区(community)工作过程中遭遇些许挫折的开发人员(以及...</description></item><item><title>也谈Linux Kernel Hacking – Kconfig与Kbuild</title><link>https://tonybai.com/2012/03/18/linux-kernel-hacking-series-kconfig-and-kbuild/</link><pubDate>Sun, 18 Mar 2012 00:00:00 +0800</pubDate><guid>https://tonybai.com/2012/03/18/linux-kernel-hacking-series-kconfig-and-kbuild/</guid><description>**_挖掘简单现象背后的复杂本质。_**– Tony Bai^\_^ 上文讲到Linux Kernel的配置和编译十分简单，甚至简单到可以与一个用户层应用相媲美。这一切都是因为Linux Kernel实现了一套易于使用、变更和后期维护的配置和编译体系。要知道最新Linux Kernel版本的代码量可是千万级别的，并且模块众多，其背后的配置和编译体系一定不那么简单，这次我们就来尝试Hack一下这套体...</description></item><item><title>也谈Linux Kernel Hacking – 内核配置、编译与安装</title><link>https://tonybai.com/2012/03/15/linux-kernel-hacking-series-kernel-config-compile-and-install/</link><pubDate>Thu, 15 Mar 2012 00:00:00 +0800</pubDate><guid>https://tonybai.com/2012/03/15/linux-kernel-hacking-series-kernel-config-compile-and-install/</guid><description>_**Linux Kernel之于C程序员，就好比世界之巅珠穆朗玛之于专业登山客。**_ — Tony Bai^\_^ 作为到目前为止最为成功的开源项目，Linux Kernel总是散发着无穷的魅力，就好比那珠穆朗玛，让人魂牵梦绕，心潮澎湃并总是想尝试征服。 记得2006年初我曾花了些时间研究Linux Kernel，但后来迷失在了Linux Kernel引导阶段，无法自拔，最终选择了&amp;#34;知难而退&amp;#34;...</description></item><item><title>C语言编码风格和标准</title><link>https://tonybai.com/2012/03/07/the-chinese-translation-of-recommended-c-style-and-coding-standards/</link><pubDate>Wed, 07 Mar 2012 00:00:00 +0800</pubDate><guid>https://tonybai.com/2012/03/07/the-chinese-translation-of-recommended-c-style-and-coding-standards/</guid><description>近期在为产品线的知识库编写一些指南类的文档，其中有一项就是对现有的C语言编码规范进行一些修订。为了&amp;#34;有米下锅&amp;#34;，我还特意在网上找了一些相关资料。关于C语言编码风格和标准的资料大多都成稿于上个世纪90年代，也就是在C90发布之后的若干年里；在C99发布后，部分资料根据最新的规范做了修订，但也有些资料认为C99对整体风格影响不大，也就保持了原样。 在这些资料中，我重点关注了一下这份文档《Recomme...</description></item><item><title>为buildc添加安装包制作相关功能</title><link>https://tonybai.com/2012/02/10/add-packing-feature-to-buildc/</link><pubDate>Fri, 10 Feb 2012 00:00:00 +0800</pubDate><guid>https://tonybai.com/2012/02/10/add-packing-feature-to-buildc/</guid><description>在&amp;#34;也谈C应用安装包制作与部署&amp;#34;一文中，我提到了为每一个源码工程建立单独的安装包制作工程(setup project)的想法，这两天我就一直在折腾这件事儿^\_^。 最初我并没有想去搞一个通用的安装包制作工具，只是为一个现有的源码工程建立了一个试验性质的安装包工程，并实现了其构建脚本(build.py)。但之后考虑到各个项目都要建立一个对应的安装包工程，安装包工程的构建脚本build.py势必会沦...</description></item><item><title>为buildc添加setup脚本</title><link>https://tonybai.com/2012/02/07/add-setup-script-for-buildc/</link><pubDate>Tue, 07 Feb 2012 00:00:00 +0800</pubDate><guid>https://tonybai.com/2012/02/07/add-setup-script-for-buildc/</guid><description>buildc在发布0.1.0版时并没有做好安装脚本，当时的建议是直接下载0.1.0的源码包或svn export/checkout源码包，并手工将buildc目录位置加入到用户的PATH环境变量中。近期buildc计划正式投入到项目中使用，为了方便大家安装以及以后的统一升级维护，我花了些时间给buildc加上了setup脚本。 Python有标准的程序分发方案，不过我对这些了解不多。buildc本...</description></item><item><title>也谈C应用安装包制作与部署</title><link>https://tonybai.com/2012/02/01/also-talk-about-c-app-install-package-making-and-deploying/</link><pubDate>Wed, 01 Feb 2012 00:00:00 +0800</pubDate><guid>https://tonybai.com/2012/02/01/also-talk-about-c-app-install-package-making-and-deploying/</guid><description>虽然部门一直在做C应用，但这么多年来，在C应用的安装包制作以及部署方面做得还是很初级，可以说还没有达到规范的程度。各个产品线的C应用安装包种类多样，水平参差不齐：有些产品的源码包即是安装包，把源码包拿到生产环境下编译后使用；有的项目则将编译好的目标文件(.o)以及第三方库放在安装包中，在生产环境下重新链接生成可执行文件；有的组则稍微专业一些，安装包中放的是编译好的可执行文件，但在目标主机上安装和执...</description></item><item><title>也谈C语言应用构建</title><link>https://tonybai.com/2012/01/17/also-talk-about-building-c-app/</link><pubDate>Tue, 17 Jan 2012 00:00:00 +0800</pubDate><guid>https://tonybai.com/2012/01/17/also-talk-about-building-c-app/</guid><description>构建是软件开发过程中最常见的活动之一，也是很容易被忽视的环节。规范以及高效的构建对软件开发过程而言是大有裨益的。C语言并非一门年轻的语言，其历史已甚为悠久了(相对于还年轻的IT领域^\_^)。从C语言诞生以来，市面上存在的C语言应用何止千千万万。这些C应用的源码组织形式种类万千，从最简单的单个源文件，到复杂的诸如Apache httpd server这样庞大的Project。不过无论这些C应用的源...</description></item><item><title>C语言项目构建管理辅助工具 – buildc</title><link>https://tonybai.com/2011/12/08/buildc-a-building-assistant-tool-for-c-app/</link><pubDate>Thu, 08 Dec 2011 00:00:00 +0800</pubDate><guid>https://tonybai.com/2011/12/08/buildc-a-building-assistant-tool-for-c-app/</guid><description>这几年我一直从事C语言项目的开发。这些项目的规模都不算小，少则十几万代码，多则几十万行代码，至少也都算得上是中型项目吧。项目构建工具使用的是传统的Make工具，构建脚本都是自行编写的，构建时直接在顶层目录下敲入make即可。 这种传统的构建方式其实是很耗时费力的。比如执行make之前你需要根据项目代码的实际路径重新设定一些环境变量或修改Makefile中的某些标识路径的变量；你还要将项目依赖的各种...</description></item><item><title>使用autoconf解决可移植性问题</title><link>https://tonybai.com/2011/08/23/solve-portable-problem-with-autoconf/</link><pubDate>Tue, 23 Aug 2011 00:00:00 +0800</pubDate><guid>https://tonybai.com/2011/08/23/solve-portable-problem-with-autoconf/</guid><description>昨天在编译项目代码时遇到了这样一个错误： xx\_base.h:72:2: 错误：#error &amp;#34;One of \_BIG\_ENDIAN or \_LITTLE\_ENDIAN must be defined.&amp;#34; 这是预编译器的错误输出。原因很明显：预编译器在处理xx\_base.h时没有发现\_BIG\_ENDIAN或\_LITTLE\_ENDIAN的定义，#error预处理宏输出了如上错误。...</description></item><item><title>偿还N年前的一笔技术债</title><link>https://tonybai.com/2011/07/21/pay-for-a-tech-debt-of-several-year-ago/</link><pubDate>Thu, 21 Jul 2011 00:00:00 +0800</pubDate><guid>https://tonybai.com/2011/07/21/pay-for-a-tech-debt-of-several-year-ago/</guid><description>记得刚来公司时曾参与过一个项目，项目中用到了部门基础库中的一个B+树接口。不过在程序调试过程中我们发现可执行程序总是dump core（在sparc solaris上），经初步分析，断定问题就出在B+树接口处，但一时又找不到问题原因。还好这个B+树的实现者就坐在我的旁边。他分析后告诉我：这个B+树接口要求用户自定义的索引结构体的size应该为4的整数倍。按照他的说法，我为结构体打了padding，...</description></item><item><title>为函数添加enter和exit级trace</title><link>https://tonybai.com/2011/07/13/add-enter-and-exit-trace-for-your-function/</link><pubDate>Wed, 13 Jul 2011 00:00:00 +0800</pubDate><guid>https://tonybai.com/2011/07/13/add-enter-and-exit-trace-for-your-function/</guid><description>日常开发中，我们为了辅助程序调试常常在每个函数的出入口(entry/exit)增加Trace，一般我们多用宏来实现这些Trace语句，例如： #ifdef XX\_DEBUG\_ #define TRACE\_ENTER() printf(&amp;#34;Enter %s\\n&amp;#34;, \_\_FUNCTION\_\_) #define TRACE\_EXIT() printf(&amp;#34;Exit %s\\n&amp;#34;, \_\_...</description></item><item><title>也谈共享库2</title><link>https://tonybai.com/2011/07/07/also-talk-about-shared-library-2/</link><pubDate>Thu, 07 Jul 2011 00:00:00 +0800</pubDate><guid>https://tonybai.com/2011/07/07/also-talk-about-shared-library-2/</guid><description>我之前写过一篇名为&amp;#34;也谈共享库&amp;#34;的博文，对共享库的查找和符号解析机制做了还算比较详细的说明，不过百密一疏，总有一些意想不到的情况发生。这不今天我又遇到了一个有关共享库的新问题，这里将这个问题及其解决过程记录下来，也算是对上一篇文章中未涉及内容的一个补充吧。 N年前我曾参与过部门的一个可复用系统的设计开发，当时我们设计了一种插件式的系统结构，其中所谓的&amp;#34;插件&amp;#34;是以共享库的形式提供。主程序通过读取配置...</description></item><item><title>使用Make的命令行变量</title><link>https://tonybai.com/2011/05/19/use-command-line-vars-of-make/</link><pubDate>Thu, 19 May 2011 00:00:00 +0800</pubDate><guid>https://tonybai.com/2011/05/19/use-command-line-vars-of-make/</guid><description>有了BuildBot搭建的持续集成环境还远未结束，具体的构建脚本还得自己来写。我们用的是Make工具，对应要编写的脚本就是Makefile。 Make是日常代码构建常用的工具，尤其是绝大多数C和C++项目都会将Make作为首选构建工具。平时多数情况大家都是直接敲入make命令便开始了构建过程，很少有人为make传入什么参数的（调试Makefile的情况除外）。但是有些时候自定义的Make命令行变量...</description></item><item><title>"%05s"行为未定义</title><link>https://tonybai.com/2010/12/17/undefined-behavior-of-05s/</link><pubDate>Fri, 17 Dec 2010 00:00:00 +0800</pubDate><guid>https://tonybai.com/2010/12/17/undefined-behavior-of-05s/</guid><description>下班前，一位同事发来的mail中提到这样一个问题：在Solaris上，新添加到Project中的一段代码编译有Warning，由于我们在Makefile的GCC命令行中设置了&amp;#34;视警告如错误&amp;#34;的-Werror编译选项，导致了项目无法成功Build。 这个Warning内容如下： warning: \`0&amp;#39; flag used with \`%s&amp;#39; printf format 产生这个Warning的...</description></item><item><title>使用Libtool创建库文件</title><link>https://tonybai.com/2010/12/14/create-libraries-with-libtool/</link><pubDate>Tue, 14 Dec 2010 00:00:00 +0800</pubDate><guid>https://tonybai.com/2010/12/14/create-libraries-with-libtool/</guid><description>除了autoconf和automake，GNU的autotools工具包中还有一种工具，它就是libtool。顾名思义，libtool是一个关于库文件制作、安装和使用的工具，它屏蔽了各个平台在库制作、安装和使用方面的差异，为上层提供了统一的接口。你可以直接使用libtool创建静态或共享库，也可以将libtool与autoconf、automake结合在一起使用。第二种方式显然更具实际意义，也更为...</description></item><item><title>也谈共享库</title><link>https://tonybai.com/2010/12/13/also-talk-about-shared-library/</link><pubDate>Mon, 13 Dec 2010 00:00:00 +0800</pubDate><guid>https://tonybai.com/2010/12/13/also-talk-about-shared-library/</guid><description>近两天一直在考量产品安装包改进的事宜。说实话，我们的安装包做得不够&amp;#34;专业&amp;#34;，不仅没有按照各个平台的标准安装包形式(比如redhat的rpm，debian的deb或solaris上的pkg包)制作，而且安装包在生产环境中还需要再进行一次链接才能得到最终的可执行程序。这样一来，每次制作安装包都很费时费力(虽然有自动打包脚本)，安装包的&amp;#34;体积&amp;#34;也很是庞大，因为包中要包含所有.o目标文件和一部分自有库以及...</description></item><item><title>lcut增加对mock的支持</title><link>https://tonybai.com/2010/10/29/lcut-add-mock-support/</link><pubDate>Fri, 29 Oct 2010 00:00:00 +0800</pubDate><guid>https://tonybai.com/2010/10/29/lcut-add-mock-support/</guid><description>记得恰好是在一个月前的今天，我发布了lcut(轻量级C语言单元测试框架)0.1.0版本 。由于发布仓促，文档没能及时跟上。在stackoverflow的一个关于单元测试的帖子 上，一位叫Craig McQueen的朋友也给出了建议：&amp;#34;Some documentation would be helpful. Project background and goals, a features list,...</description></item><item><title>关于Makefile.am中与Build相关的变量设置</title><link>https://tonybai.com/2010/10/26/about-variables-related-to-building-in-makefile-am/</link><pubDate>Tue, 26 Oct 2010 00:00:00 +0800</pubDate><guid>https://tonybai.com/2010/10/26/about-variables-related-to-building-in-makefile-am/</guid><description>今天尝试使用autoconf和automake重新构建一个遗留库的Build环境。之前改造的lcut的目录结构还是相对简单，改造时并未遇到什么难题，不过今天就没那么幸运了，我在头文件目录包含设置这个看似简单的环节上遇到了一些小麻烦。 这个库结构其实也没那么复杂，只是源文件和头文件不在一个目录下罢了： testproj/     – Makefile.am     – configure.in   ...</description></item><item><title>从mock malloc说起</title><link>https://tonybai.com/2010/10/11/start-with-mock-malloc/</link><pubDate>Mon, 11 Oct 2010 00:00:00 +0800</pubDate><guid>https://tonybai.com/2010/10/11/start-with-mock-malloc/</guid><description>上午对一段代码进行单元测试，由于需要用到mock，所以选择使用cmockery 作为Unit Testing框架(lcut还未提供mock功能)。测试代码里需要mock malloc以模拟分配内存失败的异常情况。 编写一个用例后，Build，提示出错：multiple definition of \`malloc&amp;#39;。经检查发现Makefile中定义mock malloc的那个目标文件(.o文件)居...</description></item><item><title>发布一款轻量级C语言单元测试框架</title><link>https://tonybai.com/2010/09/30/opensource-a-lightweight-c-unit-test-framework/</link><pubDate>Thu, 30 Sep 2010 00:00:00 +0800</pubDate><guid>https://tonybai.com/2010/09/30/opensource-a-lightweight-c-unit-test-framework/</guid><description>基于各种xUnit框架的单元测试早已不是什么新鲜玩意儿，不过在&amp;#34;古老&amp;#34;的C语言领域，还尚未有哪种框架可以成为“寡头”。 记得2005年末的时候，初出茅庐的我吸取xUnit的设计思想在业余时间编写了一个轻量级的C单元测试框架lcut(Lightweight C Unit Test framework)，当时还写了一篇文章《C单元测试包设计与实现》记录了最初的设计和实现思路。本打算将这个小工具在部门内...</description></item><item><title>Hello，autoconf和automake</title><link>https://tonybai.com/2010/09/26/hello-autoconf-and-automake/</link><pubDate>Sun, 26 Sep 2010 00:00:00 +0800</pubDate><guid>https://tonybai.com/2010/09/26/hello-autoconf-and-automake/</guid><description>部门绝大多数的产品都运行在Sun的小型机上，底层的操作系统是Solaris。这两年公司开始主推刀片机(物美价廉^\_^)，不过刀片机上运行的也是Solaris 10 for x86版本。基于同种OS的前提下在Sparc和x86两种体系之间做移植比较简单，主要考虑字节序问题就可以了。不过对于可移植性的考虑不足还是让我们付出了较大的工作量。 在即将进行的新版本产品开发中，可移植性依旧没有被列入到必须要...</description></item><item><title>也谈Configure脚本问题的解决</title><link>https://tonybai.com/2010/03/19/also-talk-about-solving-the-problem-of-configure-script/</link><pubDate>Fri, 19 Mar 2010 00:00:00 +0800</pubDate><guid>https://tonybai.com/2010/03/19/also-talk-about-solving-the-problem-of-configure-script/</guid><description>开了一个下午的技术交流会，回到办公室时离下班时间已经不远，天气预报说今晚有暴雪，外面阴沉的天气似乎也证实了这一点。这时一个同事遇到了一个软件包编译的问题，一时无法解决，向我求助。 这是一个libmemcached的编译问题，我们用的是libmemcached 0.34版本，我的同事在PC Solaris上执行libmemcached的configure脚本时遇到如下错，Configure脚本提示：...</description></item><item><title>简说GLIBC strncpy实现</title><link>https://tonybai.com/2009/04/15/glibc-strncpy-source-analysis/</link><pubDate>Wed, 15 Apr 2009 00:00:00 +0800</pubDate><guid>https://tonybai.com/2009/04/15/glibc-strncpy-source-analysis/</guid><description>比较以下两组代码，你认为哪组运行的更快些呢？ Example1：         int n   = 100;         int n4  = n &amp;gt;&amp;gt; 2;         int i   = 0; int a\[100\]; for (i = 0; i = 4)         {                 size\_t n4 = n &amp;gt;&amp;gt; 2; /\* n4 = n / 4， n...</description></item><item><title>GLIBC strlen源代码分析</title><link>https://tonybai.com/2009/04/11/glibc-strlen-source-analysis/</link><pubDate>Sat, 11 Apr 2009 00:00:00 +0800</pubDate><guid>https://tonybai.com/2009/04/11/glibc-strlen-source-analysis/</guid><description>直接操作C标准库提供的字符串操作函数是有一定风险的，稍有不慎就会导致内存问题。这周用业余时间写了一个小型的安全字符串操作库，但是测试之后才发现自己的实现有很大的性能缺陷。 在Solaris上初步做了一个简单的性能比对，以下是得到的性能数据(以strlen的数据为例)： 当传入的字符串长度为10时，执行100w次： strlen 执行时间是：32762毫秒 my\_strlen执行时间是：49183...</description></item><item><title>使用Scons改造现有项目</title><link>https://tonybai.com/2008/12/21/use-scons-to-build-current-projects/</link><pubDate>Sun, 21 Dec 2008 00:00:00 +0800</pubDate><guid>https://tonybai.com/2008/12/21/use-scons-to-build-current-projects/</guid><description>今天是冬至，也是入冬以来感觉最冷的一天，毫不夸张的说：你一张嘴，牙就冻上了。上午LP在家收拾卫生，我继续用Scons改造现有的项目。下午出去理发，头发长长了后，似乎会造成思维迟钝^\_^。 试验性的用Scons改造现有的project，过程中对Scons了解又多了一些。上篇文章对Scons的性能没有给出定论，经过对Scons的深入后，发现Scons在执行初始时的性能的确不够快，这是因为Scons启...</description></item><item><title>发掘Scons</title><link>https://tonybai.com/2008/12/14/learn-scons/</link><pubDate>Sun, 14 Dec 2008 00:00:00 +0800</pubDate><guid>https://tonybai.com/2008/12/14/learn-scons/</guid><description>发现或者说知道SCons是缘于Google的comp.lang.c group上的一则名为&amp;#34;Best Build Tool for large C projects &amp;#34;的帖子，帖子的作者列出了11条他认为&amp;#34;Best Build Tool&amp;#34;应该具备的特点，并欲找到这样的Build Tool。在该帖子的回复中，有人提到了Scons，说来惭愧，这是我第一次听说到有这样一个工具。一直在Unix下编写C程序...</description></item><item><title>常量类型的识别-一个小例子</title><link>https://tonybai.com/2008/12/02/an-example-for-recognizing-the-const-variable/</link><pubDate>Tue, 02 Dec 2008 00:00:00 +0800</pubDate><guid>https://tonybai.com/2008/12/02/an-example-for-recognizing-the-const-variable/</guid><description>今天闲时写了一个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\_...</description></item><item><title>分布式编译让你的工作更高效</title><link>https://tonybai.com/2008/10/14/distributed-compiling-make-you-work-more-effectivly/</link><pubDate>Tue, 14 Oct 2008 00:00:00 +0800</pubDate><guid>https://tonybai.com/2008/10/14/distributed-compiling-make-you-work-more-effectivly/</guid><description>随着工程代码量的增加，往往完整的编译一次Proj消耗的时间可能足够你喝两杯咖啡了，我现在build一次我所在proj的代码需要5分多钟，这是很痛苦的，颇让人懊恼的。为了解决这个工作中的别扭事儿，我在网上搜寻了一番，找到了distcc这个分布式编译工具。 先看看distcc能帮助我节省多少时间吧。我在公司的一台Sun SPARC Solaris9主机下对整个项目源代码按照以前的编译方式进行了一次bu...</description></item><item><title>成功Build ACE</title><link>https://tonybai.com/2007/06/14/build-ace-successfully/</link><pubDate>Thu, 14 Jun 2007 00:00:00 +0800</pubDate><guid>https://tonybai.com/2007/06/14/build-ace-successfully/</guid><description>近期公司实行新的绩效考核机制，我的考核目标中就有一项叫做：&amp;#34;成功使用新技术、框架、思路等至少3个&amp;#34;，呵呵，先不论绩效考核机制是否合理，既然已经这样了那就需要去适应。一直在做Network Application，早就知道ACE在业界中的名气，这回有理由找个时间好好挖掘一下ACE的思路，也为我的绩效目标增色啊^\_^。 以上只是开个玩笑罢了。上周末去书店看到电子工业出版社再次出版的&amp;#39;C++网络编程卷...</description></item><item><title>GCC警告选项例解</title><link>https://tonybai.com/2006/03/14/explain-gcc-warning-options-by-examples/</link><pubDate>Tue, 14 Mar 2006 00:00:00 +0800</pubDate><guid>https://tonybai.com/2006/03/14/explain-gcc-warning-options-by-examples/</guid><description>程序员是追求完美的一族，即使是一般的程序员大多也都不想看到自己的程序中有甚至那么一点点的瑕疵。遇到任意一条编译器警告都坚决不放过。有人会说：我们可以使用比编译器更加严格的静态代码检查工具，如splint。这个建议也很不错。不过lint工具使用起来较繁琐，有时候还需要记住一些特定符号并插入到你自己的代码中才行，门槛较高，这也让很多人止步于此。那么我们就从此放弃么？不，如今的编译器做得都很好，它可以帮...</description></item><item><title>用GDB调试多进程程序</title><link>https://tonybai.com/2006/01/08/debug-multiple-process-program-using-gdb/</link><pubDate>Sun, 08 Jan 2006 00:00:00 +0800</pubDate><guid>https://tonybai.com/2006/01/08/debug-multiple-process-program-using-gdb/</guid><description>有一段时间没有写技术方面的东西了^\_^。众所周知，GDB是Unix/Linux下调试程序的龙头老大，GDB功能强大，我们在平时多使用其一些最基本的功能，而且一般调试的都是单进程的程序。最近一个项目中的问题让我接触如何使用GDB调试多进程程序，更确切的是说调试调用fork的多进程程序。 使用GDB最好的文档就是其名为&amp;#39;Debugging with GDB&amp;#39;的参考手册。手册中有一小章节提到了如何调试...</description></item><item><title>Hacker Culture摘要</title><link>https://tonybai.com/2006/01/05/hacker-culture-summary/</link><pubDate>Thu, 05 Jan 2006 00:00:00 +0800</pubDate><guid>https://tonybai.com/2006/01/05/hacker-culture-summary/</guid><description>最近看了Eric S. Raymond的被称为开源文化圣典的&amp;#39;Cathedral and Bazaar&amp;#39;(大教堂与市集)以及他的另外一篇文章&amp;#39;How To Become A Hacker&amp;#39;，必须承认的是我不能够完全理解其中的内容，因为没有体验，或者说我还不够资格对Hacker Culture高谈阔论，所以这里仅作部分摘要，并说说自己第一时间的感受，望日后能温故知新。 在开始了解Hacker Cul...</description></item><item><title>打开汇编之门</title><link>https://tonybai.com/2005/11/12/open-the-gate-to-assembly-language/</link><pubDate>Sat, 12 Nov 2005 00:00:00 +0800</pubDate><guid>https://tonybai.com/2005/11/12/open-the-gate-to-assembly-language/</guid><description>工作这么长时间，一直在C语言这一层面上钻研和打拼，日积月累，很多关于C的疑惑在书本和资料中都难以找到答案。程序员是追求完美的一个种群，其头脑中哪怕是存在一点点的思维黑洞都会让其坐卧不宁。不久前在itput论坛上偶得《Computer Systems A Programmer&amp;#39;s Perspective》（以下称CSAPP）这本经典好书，遂连夜拜读以求解惑。虽说书中没有能正面的回答我的一些疑惑，但是...</description></item><item><title>一个C++项目的Makefile编写-Tony与Alex的对话系列</title><link>https://tonybai.com/2005/05/23/tony-alex-dialog-on-write-makefile-for-cpp-project/</link><pubDate>Mon, 23 May 2005 00:00:00 +0800</pubDate><guid>https://tonybai.com/2005/05/23/tony-alex-dialog-on-write-makefile-for-cpp-project/</guid><description>Tony : Hey Alex, How are you doing? Alex : 不怎么样。(显得很消沉的样子) Tony : Oh , Really ? What is the matter? Alex : 事情是这样的。最近有一个Unix下的C++项目要求我独自完成，以前都是跟着别人做，现在让自己独立完成，还真是不知道该怎么办，就连一个最简单的项目的Makefile都搞不定。昨晚看了一晚上...</description></item></channel></rss>