XRP Ninja

NOTE: I just updated the command at the bottom, again. No big change. Now all should be good to go, including building on PS3, which is big endian. Crossdev is a great tool. Thanks to vapier. However, it may not work in all circumstances, although the problems may not lie in crossdev itself. For example, when creating mips64el-unknown-linux-gnu cross toolchain. The problems happen when building glibc headers. Because at that time, we don't have cross gcc yet. So some gcc options only cross gcc supports or some macros only cross gcc defines can't be used. Also happen when building gcc on big endian machines. Because of the erroneous LD_LIBRARY_PATH setting, cc1 generated in stage 1 will try to load libgcc_s.so.1 generated in stage 1, which is little endian. So I made some work-arounds. These are the three patches needed: one patch to src_compile.eblit a second patch to src_install.eblit a third patch to gcc ebuild These are all small changes, but took me a lot of time to investi...

Update: It is said that this problem has already been fixed . I will test it later. Actually I intended to send this to LKML, but just before I was about to send I found there was already some discussions about this . So instead I decided to just post it here. To make long story short, please take a look at these two files first: The first file , which will become part of /usr/include/endian.h. This file defines both __LITTLE_ENDIAN and __BIG_ENDIAN. And this file will be included by the second file. The second file , which will be /usr/include/linux/byteorder.h Obviously, this test in the second file will fail: #if defined(__LITTLE_ENDIAN) && defined(__BIG_ENDIAN) # error Fix asm/byteorder.h to define one endianness #endif It seems that there is an inconsistency between Linux and glibc on handling __LITTLE_ENDIAN and __BIG_ENDIAN. Linux treats them like a flag, while glibc treats them like a value. glibc uses __BYTE_ORDER to determine the endianness. This problem must be...

According to my own experience, scim 1.4.4 works fine with glibc 2.5! Scim 1.4.5 must have used something which is changed from glibc 2.4 to 2.5.

I am not sure about the cause at this moment. Thanks to fcitx, I still can input Chinese. However I can't get used to it, there is some difference between the two input methods. For example in fcitx you need to press 2 keys when switching between English/Chinese, while in scim you just need to press "shift", which is the same as in MS Pinyin. Updates: Anyway, I have come back to scim (1.4.4). So good bye to fcitx! http://zhllg.blogspot.com/2006/10/latest-news-on-scim-and-glibc.html