所有C语言标准库支持的字符串操作都在string.h中，这个文件在/usr/include/下。确切的说，这个文件还包含对数组的访问。所包含的函数分为以下几类：复制、连接、比较、查找等。

void * memcpy ( void * destination, const void * source, size_t num );
void * memmove ( void * destination, const void * source, size_t num );
char * strcpy ( char * destination, const char * source );
char * strncpy ( char * destination, const char * source, size_t num );

char * strcat ( char * destination, const char * source );
char * strncat ( char * destination, char * source, size_t num );

int memcmp ( const void * ptr1, const void * ptr2, size_t num );
int strcmp ( const char * str1, const char * str2 );
int strcoll ( const char * str1, const char * str2 );
int strncmp ( const char * str1, const char * str2, size_t num );
size_t strxfrm ( char * destination, const char * source, size_t num );

const void * memchr ( const void * ptr, int value, size_t num );
const char * strchr ( const char * str, int character );
size_t strcspn ( const char * str1, const char * str2 );
const char * strpbrk ( const char * str1, const char * str2 );
const char * strrchr ( const char * str, int character );
size_t strspn ( const char * str1, const char * str2 );
const char * strstr ( const char * str1, const char * str2 );
char * strtok ( char * str, const char * delimiters );

void * memset ( void * ptr, int value, size_t num );
char * strerror ( int errnum );
size_t strlen ( const char * str );

static char *olds;

/* Parse S into tokens separated by characters in DELIM.
   If S is NULL, the last string strtok() was called with is
   used.  For example:
        char s[] = "-abc-=-def";
        x = strtok(s, "-");             // x = "abc"
        x = strtok(NULL, "-=");         // x = "def"
        x = strtok(NULL, "=");          // x = NULL
                // s = "abc\0=-def\0"
*/
char *
strtok (s, delim)
     char *s;
     const char *delim;
{
  char *token;

  if (s == NULL)
    s = olds;

  /* Scan leading delimiters.  */
  s += strspn (s, delim);
  if (*s == '\0')
    {
      olds = s;
      return NULL;
    }

  /* Find the end of the token.  */
  token = s;
  s = strpbrk (token, delim);
  if (s == NULL)
    /* This token finishes the string.  */
    olds = __rawmemchr (token, '\0');
  else
    {
      /* Terminate the token and make OLDS point past it.  */
      *s = '\0';
      olds = s + 1;
    }
  return token;
}

您可能也喜欢：

认识静态链接库

系统调用和库函数的区别

GNU工具链学习笔记

进程生命周期、主要状态及其转换关系

zz Linux下的段错误的原因及调试

无觅

相关文章：

• 使用ld的wrap选项替换已有库函数
• Expected unqualified-id before 查错
• zz Linux下的段错误的原因及调试
• Open64中的自动向量化支持
• Illegal Instruction 错误初窥
• 为龙芯电脑安装操作系统常见问题

静态链接库，即static library或 statically-linked library。和动态链接库，即dynamic library 或dynamicly-linked library相对，是Windows和Linux系统中比较常用的库文件。Windows中分别用SLL和DLL文件表示，Linux中分别是.a和.so文件.

静态链接库实际是一些object files(.o文件)和头文件的压缩包，通过GNU工具链中的ar(archiver)程序创建。

静态链接库、动态链接库和共享库

那为何还要有动态链接库呢？静态练级库虽然能很好的节省编译时间。对于一个简单的ls程序，我们需要有屏幕输出，有字符串和格式操作，有文件系统访问等等函数，都要在一个程序中。此时，这个程序会很大。一个小小的ls可能都会有好几兆。如果还有个rm程序，同样也需要屏幕输出，文件系统访问。那么这两个东西，我们可以放到两个库文件里，在执行ls，或者rm的时候，用到屏幕输出操作，就将相应的函数对应的机器码载入内存中，执行。然后再从内存中释放。接着载入文件系统访问的相关函数。这样我们的程序就能变小很多。这种可以动态装载到内存中的库文件就是动态链接库了。Windows下的DLL文件就是动态链接库。

还有个问题，其实ls和rm使用的屏幕输出函数是一样的。内存很小的时候，同时执行ls和rm，有必要同时载入两份相同的代码到内存中吗？于是就有了共享库，不同的程序可以共享相同的代码。都可以访问，执行。于是就有了共享库的概念。Linux下的.so文件就是共享库。

这时候又有个问题，程序执行时，访存，跳转的地址是一定的，那两个程序又如何共享相同的库代码呢？这就靠位置无关的代码生成了。本博曾经写过文章介绍它们，请参考Gcc和Open64中的-fPIC选项 和GCC中的pie和fpie选项两篇文章。

下图是关于共享库和静态链接库的示意图，可以简单看出些区别。

静态链接库和共享库

为什么要有静态链接库？

首先，随着程序规模的增加，有些常用函数可能不需要每次都编译，于是就可以把它们作为库的方式来存放。这样用户就能很方便的链接生成最后的程序，不用一遍遍的重新编译某些常用程序文件。必须内核，硬件驱动，文件系统，glibc等等库文件，一些基本函数都采用了这种形式。

其次，一些闭源代码，可以通过库的方式来发布，这样可以保证代码不公开。

再次，相比动态链接的程序，或者共享库程序，连接到静态库的程序会快1%-5%左右。

另外，有些特殊环境，必须使用静态链接库。比如在Linux系统，需要chroot到另一个系统环境中时，动态链接库就不再起作用，因为那些是在原来系统的文件树下，如/usr/lib.但在chroot的环境中，无法访问。

怎么用静态链接库？

既然静态链接库的出现，是为了缩短编译时间。而普通可执行程序又可以分为静态链和动态链两种形式。因此我们就分开介绍之，原因无他，只是想顺便介绍一下动态链可执行程序和静态链可执行程序在运行时的一些区别。

对于静态链接库的应用，加上-lname，就会链接libname.a这个静态链接库文件。一般静态链接库文件的搜索路径为系统默认的路径，如/usr/lib/和当前路径。你也可以用过-L选项，指定GCC搜索某个特定文件夹。注意-l和-L的参数要加载待编译源码文件之后。

静态链接库既可以在编译时用于生成单个可执行文件，也可以在运行时根据编译或者连接时确定的静态偏移量载入内存中。

编译静态链接可执行程序

编译静态链可执行程序,对于gcc，只要加上-static即可。

编译时，程序中若有对库函数的调用，编译器或者连接器就会将库中相应的代码拷贝到目标文件中，生成一个独立的可执行文件。

编译动态链接可执行程序

不加-static编译生成的可执行程序都是动态链接的，编译时所做工作很少，仅仅记录了该程序需要什么库函数，以及该库函数在库中到索引。

但对于动态链接程序，在系统启动该可执行程序时，装载器loader必须能找到相应的共享库文件.so文件或者静态链接库文件.a(已经很少使用这种形式了)，并将其载入内存中，一般的，有两种途径可以指定链接库文件的位置，

• 编译动态链接可执行程序时，通过rpath指定，这个可以在编译时增加选项-Wl,-rpath=DIRS.这种方式不需要在运行时做任何修改，该选项会在连接时，写入可执行程序中。
• 运行时由ld.so指定。默认共享库搜索路径是/usr/local/lib，/usr/lib以及当前目录，你可以通过修改$LD_LIBRARY_PATH变量修改。系统管理员也可以在/etc/profile中修改，以便对所有用户有效。当然修改/etc/ld.so.conf也行，这样所有的程序都将更改寻找链接库文件的路径。

很晕吧

静态链接库的常用操作

制作静态链接库

$ar rcs liba.a a.o b.o c.o a_header.h b_header.h

上面命令，将a.o, b.o, c.o, a_header.h, b_header.h作成静态链接库liba.a.

• 选项r：将 .o , .h文件插入到liba.a文件中
• c:创建一个压缩文件。
• s：将.o文件的索引信息写入压缩文件中，或者升级已有索引。这和执行 ranlib liba.a的效果过一样。索引信息会存在压缩包的一个符号文件夹内，连接器可以通过名称找到位置，这样可以加速连接时间。

解压静态链接库

$ar xv liba.a

该命令会把liba.a中所有的文件解压缩到当前目录下。

• x：解压缩该压缩包
• v：可视化，解压缩同时输出到屏幕

查看内容

$nm --print-armap liba.a

该命令查看liba.a中包含哪些文件，每个文件中包含哪些函数。

• 在列出压缩包中所有文件中的符号，同时包含索引：每个元素到符号的映射

实践：

本文不再给出具体实践，可以参考An Introduction to GCC – Shared libraries and static libraries

参考：

1. http://www.network-theory.co.uk/docs/gccintro/gccintro_25.html
2. http://en.wikipedia.org/wiki/Static_library
3. http://cpp.codenewbie.com/articles/cpp/1444/Static_Link_Librarys-Page_1.html
4. http://tldp.org/HOWTO/Program-Library-HOWTO/static-libraries.html
5. http://www.faqs.org/docs/linux_scratch/chapter05/whystatic.html
6. http://en.wikipedia.org/wiki/Dynamic-link_library
7. http://www.ibm.com/developerworks/linux/library/l-dynamic-libraries/index.html

您可能也喜欢：

GCC中的pie和fpie选项

Gcc和Open64中的-fPIC选项

软链接和硬链接

GNU工具链学习笔记

百度Hi策略的猜想

无觅

相关文章：

• 期待未来-一张趣图
• 前瞻-LLVM大事记(2004-2010)
• GCC初窥
• Gentoo中的交叉编译利器–crossdev
• 多面体模型是编译器循环优化的未来吗？
• zz Linux下的段错误的原因及调试

以上内容摘抄自《程序员的自我修养 –链接，装载与库》

您可能也喜欢：

GCC中的pie和fpie选项

zz Linux下的段错误的原因及调试

Gcc和Open64中的-fPIC选项

认识静态链接库

走进Debian和Gentoo中的系统初始化过程

无觅

相关文章：

• GCC初窥
• GCC中的pie和fpie选项
• Gentoo中的交叉编译利器–crossdev
• zz Linux下的段错误的原因及调试
• 使用crossdev安装龙芯的O32 gnu交叉工具链
• 用crossdev装龙芯的n32 gnu交叉工具链

这篇文章仅仅针对浏览器处理JavaScript的性能作比较，主要在X86平台和龙芯平台。先来解释一下JavaScript，JavaScript是互联网内较为常用的脚本语言，面向对象，主要在浏览器内解释执行，用于生成动态网页，因为很多语言特性受Java影响，所以叫JavaScript。通过JavaScript，浏览器可以运行服务器想要在访问者终端上运行的一些计算程序，以达到更好的浏览体验。

再说说浏览器内核和JavaScript的关系，其实JavaScrip脚本的执行仅仅是浏览器内核的一部分，其他的还有Html语言的解释执行，网页的呈现等等也是内核要做的。之所以这么关心浏览器核心对JavaScript脚本的处理情况，是因为现在的很多应用不再是简单的网页浏览，如gmail，google reader，gooe wave还有一些网页3D特效等等都需要在客户机上作计算，这就需要JavaScript大显身手了。而且越来越多的应用依赖JavaScript，所以现在浏览器对JavaScript的处理速度直接影响着用户体验。目前WebKit的JavaScript引擎SquirrelFish，JavaScript的引擎是SpiderMonkey

目前JavaScript在大多数平台上的处理是靠解释执行的，又因为是动态类型，面向对象。。。，决定了JavaScript执行效率低，所以就诞生了各种针对JavaScript的优化，也有了测试JavaScipt解释器性能的BenchMark，目前常用的是Sunspider和google V8，这篇文章中的对比针对Sunspider测试集。

另外还要说说JIT，Just In time，转换，将部分程序代码直接转换成机器码执行，这种技术在运行时优化中比较常用，JavaScript是解释器，所以JIT在解释器中也是很重要的优化手段。目前X86的webkit和Firefox默认就有JIT支持，但龙芯平台上还没有，本博也是最早对龙芯2F平台有JIT支持的Webkit和firefox  JavaScript引擎作对比的，目前这两个JIT都还没有进入官方的代码库中，感兴趣的朋友可以在下面的前两个链接中找到相关源码。其中webkit的补丁还要做些宏的修改，改动不大。这两个都是从官方源码库checkout出来并修改之后的。其中firefox的JIT部分是由ZSC大牛写出来的，详细的讨论贴和测试结果可以在龙芯论坛看到，见下面的第三个链接。
x86下epiphany(webkit内核)和firefox开了jit之后的性能，如下

webkit Total:                  833.6ms +/- 2.1%
firefox Total:                 1774.4ms +/- 2.7%

（测试环境是我的笔记本 intel Pentium t2390,开了频率调节，所以波动较大)、两个差距：

TEST                   COMPARISON            FROM                 TO             DETAILS

=============================================================================

** TOTAL **:           2.13x as fast     1774.4ms +/- 2.7%   833.6ms +/- 2.1%     significant

=============================================================================

  3d:                  2.96x as fast      257.2ms +/- 2.1%    87.0ms +/- 1.0%     significant
    cube:              3.36x as fast       79.2ms +/- 1.7%    23.6ms +/- 2.9%     significant
    morph:             1.52x as fast       50.4ms +/- 1.4%    33.2ms +/- 3.1%     significant
    raytrace:          4.23x as fast      127.6ms +/- 3.0%    30.2ms +/- 3.4%     significant

  access:              3.26x as fast      237.0ms +/- 4.7%    72.8ms +/- 2.8%     significant
    binary-trees:      8.82x as fast       67.0ms +/- 4.4%     7.6ms +/- 9.0%     significant
    fannkuch:          3.48x as fast       98.2ms +/- 0.6%    28.2ms +/- 3.7%     significant
    nbody:             2.50x as fast       51.4ms +/- 10.3%    20.6ms +/- 3.3%     significant
    nsieve:            -                   20.4ms +/- 56.6%    16.4ms +/- 4.2% 

  bitops:              1.42x as fast       53.8ms +/- 1.9%    38.0ms +/- 0.0%     significant
    3bit-bits-in-byte: *3.10x as slow*      2.0ms +/- 0.0%     6.2ms +/- 9.0%     significant
    bits-in-byte:      -                   11.0ms +/- 8.0%    10.4ms +/- 6.5%
    bitwise-and:       *2.33x as slow*      3.0ms +/- 0.0%     7.0ms +/- 0.0%     significant
    nsieve-bits:       2.62x as fast       37.8ms +/- 1.5%    14.4ms +/- 4.7%     significant

  controlflow:         8.76x as fast       50.8ms +/- 2.0%     5.8ms +/- 9.6%     significant
    recursive:         8.76x as fast       50.8ms +/- 2.0%     5.8ms +/- 9.6%     significant

  crypto:              2.34x as fast       93.8ms +/- 1.7%    40.0ms +/- 2.2%     significant
    aes:               2.57x as fast       54.0ms +/- 3.6%    21.0ms +/- 4.2%     significant
    md5:               2.62x as fast       26.2ms +/- 2.1%    10.0ms +/- 0.0%     significant
    sha1:              1.51x as fast       13.6ms +/- 5.0%     9.0ms +/- 0.0%     significant

  date:                1.87x as fast      275.2ms +/- 2.0%   147.0ms +/- 1.0%     significant
    format-tofte:      2.75x as fast      149.0ms +/- 1.0%    54.2ms +/- 1.0%     significant
    format-xparb:      1.36x as fast      126.2ms +/- 4.0%    92.8ms +/- 1.7%     significant

  math:                1.12x as fast       89.8ms +/- 1.8%    80.2ms +/- 21.7%     significant
    cordic:            2.13x as fast       43.4ms +/- 3.3%    20.4ms +/- 9.2%     significant
    partial-sums:      *1.41x as slow*     34.4ms +/- 2.0%    48.6ms +/- 38.2%     significant
    spectral-norm:     1.07x as fast       12.0ms +/- 0.0%    11.2ms +/- 12.2%     significant

  regexp:              3.73x as fast      125.4ms +/- 15.5%    33.6ms +/- 2.0%     significant
    dna:               3.73x as fast      125.4ms +/- 15.5%    33.6ms +/- 2.0%     significant

  string:              1.80x as fast      591.4ms +/- 3.3%   329.2ms +/- 1.6%     significant
    base64:            *1.24x as slow*     28.4ms +/- 2.4%    35.2ms +/- 1.6%     significant
    fasta:             1.71x as fast      133.0ms +/- 2.3%    78.0ms +/- 4.6%     significant
    tagcloud:          2.81x as fast      169.4ms +/- 3.8%    60.2ms +/- 8.2%     significant
    unpack-code:       1.91x as fast      193.8ms +/- 4.4%   101.6ms +/- 2.7%     significant
    validate-input:    1.23x as fast       66.8ms +/- 5.8%    54.2ms +/- 6.4%     significant

龙芯上的JIT具体对比数据不便透漏，可以从下面第三个链接中找到第一版发布时的测试数据。这里仅仅给出一个对比。webkit之所以with GUI是使用编译出的迷你小浏览器中测试结果，no GUI是使用测试脚本跑出来的结果。

 Webkit with GUI Total:                  6723.4ms +/- 0.5%
        no GUI   Total:                  6355.8ms +/- 0.5%
 Firfox Total 7000 ms 左右。

注： 龙芯中的JIT现在还不够成熟，其中Webkit的JIT仅是针对MIPS III做的，没有针对龙芯的特殊优化。

另外，X86中firefox的版本是3.5.7，龙芯中firefox的版本是3.7pre1.WebKit在X86中版本是epiphany的2.28中的版本，龙芯中为SVN中的2010-01-12 r53114。X86运行环境为Gentoo，Gcc4.4.2,Glibc2.11,龙芯运行环境是玲珑一体机，GCC4.3(龙梦修改版）,Glibc2.10。

对比结果可见：X86中WebKit浏览器的性能要明显优于Firefox，达到两倍之多。龙芯相比起来还有些差距，不过相信优化后龙芯的性能会更好。

参考

https://bugs.webkit.org/show_bug.cgi?id=30144

http://dev.lemote.com/code/firefox-3.7-loongson-jit

http://lemote.com/bbs/viewthread.php?tid=26687&extra=page%3D1

http://en.wikipedia.org/wiki/Google_Chrome

http://ineolee.com/pc/several-browser-core-introduction/

您可能也喜欢：
webkit-龙小组成立	zzMozilla的疯狂构想 Firefox 4将开拓浏览器新疆界	龙芯N32系统上的Squirrelfish性能	JIT Compiler and Virtual Machine SW Engineer for Web Browsers in Qualcomm	擦亮眼睛 “百度Hi”用户协议有猫腻
无觅

相关文章：

• 拥有Nanojit龙芯后端的firefox发布(10年1月14日更新)
• GCC初窥
• 用crossdev装龙芯的n32 gnu交叉工具链
• 使用crossdev安装龙芯的O32 gnu交叉工具链
• Gentoo中的交叉编译利器–crossdev
• 龙芯N32系统上的Squirrelfish性能

言归正传：
之所以暴力了一把，是因为换了几次源，运行了几次apt-get update之后，终于install了qtcreator，但是却要更新glibc,结果更新了半天，重启，发现xserver-xorg不见了。于是安装，就开始报版本冲突：
xserver-xorg: Depends: xserver-xorg-core (>= 2:1.7) but 2:1.6.5-1 is to be installed
折腾了好久都不行，一怒之下，从别的玲珑上直接拷来了/usr/bin和lib下的X文件，呵呵，居然能用了。但是也仅仅限于启动了kdm，接下来登录就开始报
X: unable to open wrapper config file /etc/X11/Xwrapper.config
X: user not authorized to run the X server, aborting.
身心俱疲了，改天再搞，先ssh -Y用着吧。改天写个总结。

您可能也喜欢：

GCC即将支持龙芯3A

龙芯电脑常见问题

zzzz龙芯之火，可以燎原（下）

zz 龙芯之火，可以燎原（上）

关于龙芯公司的小道消息

无觅

相关文章：

• 小例子–回眸一笑百媚生
• zz Linux下的段错误的原因及调试
• 走进Debian和Gentoo中的系统初始化过程
• Ebuild and emerge
• 用crossdev装龙芯的n32 gnu交叉工具链
• 龙芯电脑常见问题

引入PIE的原因是让程序能装载在随机的地址，通常情况下，内核都在固定的地址运行，如果能改用位置无关，那攻击者就很难借助系统中的可执行码实施攻击了。类似缓冲区溢出之类的攻击将无法实施。而且这种安全提升的代价很小

谈到PIE就不得不说说Pax和Grsec内核。这两个东西都是为了构建坚不可摧到安全系统而准备的。PaX是Linux内核安全增强补丁，它能在两方面保证安全性，一是ASLR(Address Space Layout Randomization,地址空间分布随机化)，这是一种将所有数据装载到内存时都随机化地址的方式，当使用PIE选项编译应用时，PaX能将应用的地址做随机加法；二是能提供不可执行的内存空间，这样就能使得攻击者放入内存中的恶意代码不可执行。不过PaX官网上能支持的最新内核是2.6.27，已经是一年前的更新了。Grsec也时类似的内核补丁，更新较为频繁能支持最新的2.6.32内核。这两种方式都能将内核完全位置无关，除了Grub和Glibc中无法位置无关的汇编码。

PIE最早由RedHat的人实现，他在连接起上增加了-pie选项，这样使用-fPIE编译的对象就能通过连接器得到位置无关可执行程序。fPIE和fPIC有些不同。可以参考Gcc和Open64中的-fPIC选项.

gcc中的-fpic选项，使用于在目标机支持时，编译共享库时使用。编译出的代码将通过全局偏移表(Global Offset Table)中的常数地址访存，动态装载器将在程序开始执行时解析GOT表项(注意，动态装载器操作系统的一部分，连接器是GCC的一部分).而gcc中的-fPIC选项则是针对某些特殊机型做了特殊处理，比如适合动态链接并能避免超出GOT大小限制之类的错误。而Open64仅仅支持不会导致GOT表溢出的PIC编译。
gcc中的-fpie和-fPIE选项和fpic及fPIC很相似，但不同的是，除了生成为位置无关代码外，还能假定代码是属于本程序。通常这些选项会和GCC链接时的-pie选项一起使用。fPIE选项仅能在编译可执行码时用，不能用于编译库。所以，如果想要PIE的程序，需要你除了在gcc增加-fPIE选项外，还需要在ld时增加-pie选项才能产生这种代码。即gcc -fpie -pie来编译程序。单独使用哪一个都无法达到效果。
你可以使用file命令来查看当前的可执行文件是不是PIE的。

下面是本博编译helloword的显示。可以看出，可执行文件属性从executable变成了shared object.
$ gcc  helloworld.c
$ file a.out
a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
$ gcc -fpie -pie helloworld.c
$ file a.out
a.out: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
接下来，我们就能实验了，使用strace命令来查看这两个a.out执行情况了。关于strace命令，可以参考strace命令介绍
在博主电脑上，有PIE时，执行第一个brk(0)系统调用时，返回的地址一直是变化的。而无PIE时，brk(O)系统调用返回地址一直不变。内容太多，不再贴出。

注：
linux系统调用brk()：
linux系统内部分配内存的系统调用，malloc()其实也是调用的brk().直接修改堆的大小，返回新内存区域的结束地址。

参考：
http://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html

http://www.linuxfromscratch.org/hlfs/view/unstable/glibc-2.6/chapter02/pie.html

http://www.gentoo.org/proj/en/hardened/hardened-toolchain.xml
http://www.gentoo.org/proj/en/hardened/pax-quickstart.xml
http://www.kernel.org/doc/man-pages/online/pages/man2/brk.2.html
<Understanding Linux Kernel> 3rd Edition Page32 , Page395

您可能也喜欢：

Gcc和Open64中的-fPIC选项

Open64课程–付诸实践(Practical Matters)

open64课程–过程间分析优化(IPA)

Open64课程–OpenMp和自动并行化

Open64 课程–全局标量优化(WOPT II)

无觅

相关文章：

• GCC初窥
• 认识静态链接库
• GNU工具链学习笔记
• Gentoo中的交叉编译利器–crossdev
• Gcc和Open64中的-fPIC选项
• 用crossdev装龙芯的n32 gnu交叉工具链

言归正转，开始安装我们的O32工具链，因为使用crossdev(如果你还不知道什么是crossdev，请参考Gentoo中的交叉编译利器–crossdev)，我们仍旧需要配置龙芯的overlay。详细的配置过程参见用crossdev装龙芯的n32 gnu交叉工具链，我这里只简单列出命令：
cd /root
git clone git://www.gentoo-cn.org/var/git/loongson.git
cd /usr/local/portage/
mkdir loongson
cd loongson
ln -s /root/loongson-overlay/sys-libs/ sys-libs ##glibc指向overlay中的glibc
ln -s /root/loongson-overlay/sys-devel/ sys-devel ##将gcc指向overlay中的gcc

接下来修改make.conf，确保/usr/local/portage/loongson在你所有overlay查找的最前面：
PORTDIR_OVERLAY="/usr/local/portage/loongson $PORTDIR_OVERLAY"
这样做是为了确保使用龙芯overlay中的gcc和binutils。

下面还不能直接执行
crossdev -t mipsel-unknown-linux-gnu
因为现在overlay还不支持O32的工具链，需要我们做些修改，这些修改是我安装的时候google并参考zhllg在n32工具链的bugfix做的，目前能正常安装并能编译运行helloworld，应该没有任何问题:)

在目录/usr/local/portage/loongson/sys-libs/glibc下，做如下修改
files/eblits/src_compile.eblit
160a161,167
+ if [[ ${CTARGET} == "mipsel-unknown-linux-gnu" ]] ; then
+ # remove "-32" gcc switch, since gcc for other arch don't have this
+ sed -i '2 s/-mabi=32//g' "${S}"/ports/sysdeps/mips/mips32/Makefile
+ # fix stdio_lim.h missing problem
+ sed -i 's/_MIPS_SZPTR/32/' "${S}"/ports/sysdeps/mips/bits/wordsize.h
+
+ fi
files/eblits/src_install.eblit
203a204,207
+ if [[ ${CTARGET} == "mipsel-unknown-linux-gnu" ]] ; then
+ sed -i 's/\(__WORDSIZE.\+\)\(32\|64\)$/\1_MIPS_SZPTR/' \
+ "${D}"/$(alt_headers)/bits/wordsize.h || die "restore wordsize.h failed"
+ fi
上面修改共三处，第一处解决emerge glibc-header时报的 gcc doesn’t support -mabi=32 错。修改方式是直接删除此选项，因为我们使用x86上的gcc而这个选项是支持O32的gcc才能接受的选项。
第二，三处修改解决同一个问题，Emerging cross-gcc-stage1时出错/usr/mipsel-unknown-linux-gnu/sys-include/stdio.h error: bits/stdio_lim.h: No such file or directory。 对于这个错误，你有两种修改方式，可以直接touch stdio_lim.h这个文件，这是很多手工编译工具链时给的建议。这里我们使用另一种方法，阻止该文件被include到stdio.h中，这是zhllg在N32工具链中使用的方式。

修改完了之后别忘了重新生成ebuild校验。
ebuild glibc-2.10.1.ebuild manifest
ebuild glibc-2.9_p20081201-r2.ebuild manifest

bug修改完成，接下来，你就可以直接使用crossdev安装了。
crossdev -t mipsel-unknown-linux-gnu

Enjoy it！

PS：

1. 这是自己第一次修改ebuild，呵呵其实很简单，但自己一直都把自己当成用户，没有做过这种事，不敢做，所以浪费了很多时间，看着自己改出来的bug，心情很不一样哈。
2. 我已经将上面的修改提交给了zhllg，等他做了相应的修改，就可以直接crossdev安装了。请关注此文。

您可能也喜欢：

关于龙芯公司的小道消息

龙芯N32系统上的Squirrelfish性能

webkit-龙小组成立

用crossdev装龙芯的n32 gnu交叉工具链

胡伟武：龙芯5年内改变全球CPU格局

无觅

相关文章：

• 用crossdev装龙芯的n32 gnu交叉工具链
• Gentoo中的交叉编译利器–crossdev
• Ebuild and emerge
• gentoo如何处理被屏蔽(masked)的包 by 杨珂 转自linuxsir
• 小例子–回眸一笑百媚生
• GCC初窥

我们需要首先有gentoo的龙芯overlay，这个overlay是gentoo开发者zhllg维护的龙芯gentoo n32系统的overlay，因为我们需要n32的glibc，所以就需要这个overlay。虽然你可以直接只下载glibc的相关文件，但是推荐你直接clone整个overlay，这样的话，以后你就可以直接用git工具和zhllg的overlay更新了。如果不懂什么是overlay，可以参考这个链接Gentoo Overlays: Users’ Guide。你需要一个位置存放overlay的内容，因为我们只需要glibc，所以你最好放在/usr/local/portage/以外的地方，然后在/usr/local/portage/做glibc的链接到龙芯的overlay里，这样能避免安装其他软件中的龙芯支持，搞乱你自己的x86系统。假定你在/root下存放overlay。你需要执行以下命令:
cd /root
git clone git://www.gentoo-cn.org/var/git/loongson.git
cd /usr/local/portage/
mkdir loongson
cd loongson
ln -s /root/loongson-overlay/sys-libs/  sys-libs    ##glibc指向overlay中的glibc
ln -s /root/loongson-overlay/sys-devel/  sys-devel  ##将gcc指向overlay中的gcc
至于为啥要把gcc也做软链接到龙芯的overlay，其实是因为历史遗留问题，原来的gcc4不支持，需要打补丁，现在不需要了，不过以后可能还需要，所以就做了这个软链接，不过你到overlay里，ls -l一下可以看到其实overlay里gcc也是链接，指向/usr/portage/下的gcc。

接下来就要告诉emerge，从overlay中找工具链中的gcc/binutils/glibc。我们要编辑/etc/make.conf文件，添加本地龙芯的portage，这里要注意，之所以我在/usr/local/portage下又创建文件夹是因为我有layman。另外你需要确保/usr/local/portage/loongson在你所有overlay查找的最前面：
PORTDIR_OVERLAY="/usr/local/portage/loongson $PORTDIR_OVERLAY"
这样做是为了确保使用龙芯overlay中的gcc和binutils。

接下来就能直接安装了：
crossdev -t mips64el-unknown-linux-gnu

之后你就能享受交叉编译了，mipsel-unknown-linux-gnu-gcc 编译个helloword试试吧:)

龙芯是咱们自己的东西，大家一起努力才能让龙芯走向世界！

这里要注意几个问题：
1，如果你是新安装的glibc，龙芯overlay中的glibc是2.10的，你gentoo系统的glibc的版本不能比这个低才行，不然会有冲突，具体的错误提示我忘记了。
2，一定要让龙芯overlay在PORTDIR_OVERLAY的最前面。
3，具体安装以下内容
linux-headers-2.6.27-r2 from portage.
binutils-2.19.1-r1 from loongson overlay.
gcc-4.4.2 from portage. The gcc in loongson overlay currently is just a symlink to portage gcc.
glibc-2.10.1 from loongson overlay.

参考

http://r0bertz.blogspot.com.sixxs.org/2009/11/update-on-building-mips64el-cross.html

您可能也喜欢：

龙芯N32系统上的Squirrelfish性能

webkit-龙小组成立

使用crossdev安装龙芯的O32 gnu交叉工具链

关于龙芯公司的小道消息

胡伟武：龙芯5年内改变全球CPU格局

无觅

相关文章：

• 使用crossdev安装龙芯的O32 gnu交叉工具链
• Gentoo中的交叉编译利器–crossdev
• Ebuild and emerge
• GCC初窥
• GCC中的pie和fpie选项
• gentoo如何处理被屏蔽(masked)的包 by 杨珂 转自linuxsir