Free as in freedom

about gentoo-cn.org

2011-08-20T01:28:00.003+08:00

There's been some problem renewing this domain. We might as well abandon this domain name altogether and switch to gentoo-zh.org. Actually I have already registered the later one.

Probably will set it up this weekend.

Meanwhile you can access the site using zhangle.is-a-geek.org. Everything works fine, except sub domains, like {planet,irc...}.gentoo-cn.org.

Sorry for the convenience caused, if any.

gentoo-zh overlay

2011-06-12T03:36:00.003+08:00

So gentoo-china and gentoo-taiwan overlay will merge. The new overlay will be called gentoo-zh.
I have already added gentoo-zh overlay to repositories.xml based on which layman-global.txt is generated.

Thanks to microcai for merging the repository of these two projects.

EDIT: sorry there is an error about the source type. already fixed.

New job, New life

2011-02-21T08:28:00.002+08:00

So, as some of you may know, I have just settled down in San Jose, CA.
My new job is Site Reliability Engineer in Google Mountain View office.

I would like make some new friends here.
If you live nearby, let me know, ;)

Linux 2.6.35 + glibc compiled with >linux-header-2.6.34 == Unusable MIPS N32 System

2010-12-19T18:14:00.006+08:00

getdents64 was added to N32 ABI during 2.6.35 merge window. But it has a problem which is later fixed by a patch merged in 2.6.36 window.

IIRC, readdir in glibc works with both getdents and getdents64, and it prefers getdents64 if it is available.

So if your glibc is compiled against linux-header-2.6.35 and upwards, readdir will use getdents64, but on Linux 2.6.35 it actually calls getdents. So readdir will be confused.

As a consequence, you will have problems accessing files. The system will be effectively unusable.

So if you have encountered this problem, pray that you have another system which could boot the machine. Compile a kernel 2.6.36 or upwards and use it to boot the system. Then you should be able to get your system back.

MIPS N32 Firefox

2010-09-15T11:10:00.004+08:00

Almost forget to mention, now with this workaround http://bit.ly/d5rBqp, N32 firefox-3.6.8 is working again.

I am still trying to fix the binutils bug.
http://sourceware.org/bugzilla/show_bug.cgi?id=11956
I am feeling that I am not far from a break through.

BTW, Shenzhen Linux User Group will celebrate Software Freedom Day 2010 on this Saturday.
If you happen to be in town by then, do drop by, ;)

http://bit.ly/sz_sfd_2010
If you can come, and don't understand Chinese, I am always ready for help. ;)

Loongson 2F N32 stage3 is now available on gentoo mirrors

2010-07-29T09:51:00.005+08:00

It is under experimental/mips/stages/loongson/. Like:
http://mirrors.xmu.edu.cn/gentoo/experimental/mips/stages/loongson/
I should have done it long ago, just don't familiar with catalyst and catalyst lacks documentation.

Thanks to leio and robbat2 for making it happen.
http://bugs.gentoo.org/show_bug.cgi?id=330021

I have already included kernel modules in the stage3. You can find the corresponding kernel here:
http://www.gentoo-cn.org/~zhangle/

If you want to build your own kernel, use the source here:
http://dev.lemote.com/code/linux-loongson-community/wiki/WikiStart

You also need loongson overlay. Just use layman to add it. Of course you need to emerge layman first.
http://www.gentoo-cn.org/gitweb/?p=loongson.git;a=summary

If you find portage ask you to downgrade packages, you can try this trick
ACCEPT_KEYWORDS="x86 ~x86 ~mips"
However you need to understand that there is no guarantee that software installed in this way would work. But at least some of them will work. Like perl. I have been using this for a long time. Some packages are not so easy to downgrade. So maybe you need to use this too. But remember, if the package really works, better file a keyword bug asking devs to add mips keyword to it.

Please note this is experimental, so I am afraid there will be problems. If you hit any, please don't hesitate to contact me.

Type special characters in xterm in N900

2010-07-18T20:41:00.012+08:00

UPDATE: The build failed because of gcc's multislot USE flag(seed stage has it while catalyst can't set USE for stage3). I was on a trip so there is actually no progress for the last 5 days. Sorry. I have worked around it. Now rebuilding.

First, sudo gainroot.

Then run the following two commands:

/home/user # gconftool-2 -s /apps/osso/xterm/key_labels -t list --list-type=string '[Tab,Esc,~,`,|,>,<]'
/home/user # gconftool-2 -s /apps/osso/xterm/keys -t list --list-type=string "[Tab,Escape,asciitilde,grave,bar,greater,less]"

Then restart your xterm, you will see the bottom bar looks like the one showing in the following picture:

This picture shows that I am building new stage3 for Loongson 2F, N32 ABI, ;)

FEATURES installsources not working on MIPS?

2010-05-21T16:31:00.008+08:00

Update 2010-07-09: the patch received upstream attention. The maintainer said it's better to send to rpm-devel@rpm5.org directly.
Update: just reported to upstream http://rpm5.org/cvs/tktview?tn=61

I resumed my quest to xulrunner linking problem on Loongson: http://old.nabble.com/R_MIPS_TLS_GD-reloc-overflow-when-linking-%3E%3Dxulrunner-1.9.1.5-td26755056.html

But I found that "installsources" FEATURE is not working on Loongson. I investigated it and found that it is because debug.sources file produced by debugedit is empty.

Then I found that in turn was because debug related sections in MIPS elf file is not of type SHT_PROGBITS, but SHT_MIPS_DWARF.


[32] .debug_aranges    MIPS_DWARF      00000000 0845c4 0002c0 00      0   0  1
[33] .debug_pubnames   MIPS_DWARF      00000000 084884 001a2a 00      0   0  1
[34] .debug_info       MIPS_DWARF      00000000 0862ae 015221 00      0   0  1
[35] .debug_abbrev     MIPS_DWARF      00000000 09b4cf 002c9a 00      0   0  1
[36] .debug_line       MIPS_DWARF      00000000 09e169 009ce3 00      0   0  1
[37] .debug_str        MIPS_DWARF      00000000 0a7e4c 0049d7 01  MS  0   0  1
[38] .debug_loc        MIPS_DWARF      00000000 0ac823 004c7d 00      0   0  1
[39] .debug_macinfo    MIPS_DWARF      00000000 0b14a0 1cf9d6 00      0   0  1
[40] .debug_ranges     MIPS_DWARF      00000000 280e76 0001d8 00      0   0  1

So the fix is very easy and straight forward.


--- debugedit.c.orig    2010-05-21 16:26:13.000000000 +0800
+++ debugedit.c 2010-05-21 01:44:08.000000000 +0800
@@ -1596,6 +1596,7 @@
  switch (dso->shdr[i].sh_type)
   {
   case SHT_PROGBITS:
+       case SHT_MIPS_DWARF:
     name = strptr (dso, dso->ehdr.e_shstrndx, dso->shdr[i].sh_name);
     /* TODO: Handle stabs */
#if 0

Show real swap usage for each individual process

2010-04-18T00:23:00.010+08:00

Update: the kernel patch is already in 2.6.34-rcN.

Currently, in top, the SWAP column only shows the difference between VIRT and RES:

    case P_SWP:
     MKCOL(scale_num(PAGES_TO_KB(p->size - p->resident), w, s));

So currently the value is of no use.

As a matter of fact, a recent enough kernel has provided the information which is needed to calculate the swap usage for each process. It is in /proc/$PID/smaps. But using smaps may affect top's performance because you have to calculate the sum yourself.

But with this patch https://patchwork.kernel.org/patch/56929/, the kernel will keep track of each process's swap usage for you. This patch (maybe not exactly in the same shape) is already in mmotm tree (http://userweb.kernel.org/~akpm/mmotm/) 2.6.34-rcN.

However, checking the /proc/$PID/status file directly may not be a thing which people would like to do. So I decided to make a patch for ps and top. Now it seems to be working.

This is the vanilla ps:
$ ps -o m_swap,comm -e | grep firefox
- firefox

This is modified ps:
$ ./ps/ps -o m_swap,comm -e | grep firefox
2984 firefox

This is a picture showing a modified top:

The patch can be found here:
http://dev.gentoo.org/~r0bertz/per-process-swap-usage.patch

Generate coredumps automatically in specified directory

2010-04-03T18:22:00.002+08:00

If you are into investigating coredumps, or you are just curious about how many processes have coredumped, then this is for you:

1. add the following line to /etc/security/limits.conf

* - core unlimited

2. add the following line to /etc/sysctl.conf

kernel.core_pattern = /corefiles/core.%e.%p

%e is the executable filename, %p is pid.
Please check the "Naming of core dump files" section of man 5 core for more information on this.

3. run "sysctl -p", then logout and login. Or just reboot.

This is what I have on my Yeeloong:
$ ls /corefiles/
core.genstrings.11832 core.nscd.10278 core.nscd.12821 core.nscd.13617 core.nscd.23172 core.nscd.29367 core.nscd.6428
core.genstrings.18210 core.nscd.10281 core.nscd.13061 core.nscd.13620 core.nscd.23175 core.nscd.29368 core.nscd.6431
core.main.19478 core.nscd.10284 core.nscd.13064 core.nscd.19028 core.nscd.24042 core.nscd.29369
core.main.19702 core.nscd.10293 core.nscd.13067 core.nscd.19031 core.nscd.29353 core.nscd.29371
core.main.19825 core.nscd.10294 core.nscd.13219 core.nscd.22710 core.nscd.29360 core.nscd.29372
core.main.19894 core.nscd.12815 core.nscd.13222 core.nscd.22713 core.nscd.29363 core.nscd.29373
core.mkhomedir_helpe.31721 core.nscd.12818 core.nscd.13614 core.nscd.22716 core.nscd.29366 core.nscd.6425

Gentoo Penguins

2010-03-13T19:35:00.004+08:00

One of my friends has been to Antarctica.
She has taken some photos of Gentoo Penguin.
Enjoy! (and sorry the blog is in Chinese. :P)

http://blog.sina.com.cn/s/blog_657eb8a70100h34p.html

Germany Training confirmed

2009-12-21T14:15:00.001+08:00

Anyone in Nuremberg? ;)

Activity : Linux Kernel Internals and Crash Dump Analysis
Activity Code : Linux-IHC-001
Type : Internally Held Classroom
From : 01/26/2010
To : 01/28/2010
Facility: EMEA - Nuernberg, DEU

silent splash progress bar does not progress

2009-11-29T03:05:00.004+08:00

I got a laptop from my employer (Novell) nearly 3 months ago. I installed both Gentoo and SLED in it. I didn't setup fbsplash on it when I installed Gentoo. I tried it today.

However, I found the progress bar in silent mode did not progress. It stayed at "Initializing kernel", 0%.

Finally, I found the reason was that I didn't have "/lib/rc/plugins" directory and as a consequence splashutils openrc plugin splash.so can't be installed into this directory. And that's why the progress bar does not progress.

I think maybe it is a bug in openrc. But I am not sure and I can't investigate it further today, it is already 3 pm. :( So I just left a note here. :)

Update on building mips64el cross toolchain

2009-11-08T16:48:00.007+08:00

1. git clone git://www.gentoo-cn.org/var/git/loongson.git

2. Don't include loongson overlay's directory directly in your PORTDIR_OVERLAY. But in your own overlay, like /usr/local/portage, create symlinks pointing to sys-devel/ and sys-libs/glibc in loongson overlay. This is because you may not want to install packages from loongson overlay in your host machine. Also you need to make sure your own overlay is the first overlay containing binutils/gcc/glibc in your PORTDIR_OVERLAYS list. You may check the value of this list using command:

portageq envvar PORTDIR_OVERLAY

3. Then, just run crossdev -t mips64el-unknown-linux-gnu. This command installed the following components on my host machine:

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.9_p2009042 from loongson overlay. However if you build the toolchain now, glibc-2.10.1 will be installed instead, I just updated it.

Setting CFLAGS on a per-package basis

2009-08-01T16:42:00.004+08:00

Update: as reported by Fai Wong, -O1 is actually fine. Obviously, it must be some flag(s) which is(are) enabled at -O2 but not at -O1 caused this problem. However, it is not a priority ATM. Anyone who is interested in it is welcome to investigate it further.

As I have mentioned earlier, sqlite compiled with -O2 may cause xulrunner to segfault in N32 userland on Loongson. Well, I almost forget it.

So to remove the -O2 from CFLAGS once and for all, I adopted the technique described here.

zhangle@2f env $ pwd
/etc/portage/env
zhangle@2f env $ find
.
./dev-db
./dev-db/sqlite
./O2-removal
zhangle@2f env $ cat O2-removal
pre_pkg_setup() {
      elog "bashrc is removing \"-O2\" from CFLAGS for $PN"
      CFLAGS="${CFLAGS/-O2/}"
}
zhangle@2f env $ ls -l dev-db/sqlite
lrwxrwxrwx 1 zhangle zhangle 13 2009-08-01 16:10 dev-db/sqlite -> ../O2-removal

About the kernel of Loongson 2F machine

2009-07-31T00:57:00.003+08:00

I just found that, it is actually very easy to trigger the problem that the -mfix-ls2f-kernel as option could fix. Like just emerging glibc could hang the system. So if you are using linux-loongson/2.6.30/stable branch from this git tree http://dev.lemote.com/git?p=rt4ls.git;a=summary, you maybe want to line 129 of arch/mips/Makefile:

$(call cc-option,-march=loongson2f,-march=r4600) $(call cc-optoin,-mtune=loongson2f)

$(call cc-option,-march=loongson2f,-march=r4600) $(call as-option,-Wa$(comma)-mfix-ls2f-kernel,)

Actually, $(call cc-optoin,-mtune=loongson2f) here is not required.

BTW, glibc-2.10.1 is ready in my overlay. This version could solve the gdb issue:

Error while reading shared library symbols:
find_new_threads_callback: cannot get thread info: generic error
find_new_threads_callback: cannot get thread info: generic error

This happened previously when debugging multithread applications.

More on Yeeloong status

2009-07-27T01:42:00.007+08:00

I have not blogged here for some time. But that does not necessarily mean I am slacking, ;). Instead I have been doing things. I should've blogged more.

http://www.gentoo-cn.org/gitweb/?p=loongson.git;a=shortlog

Redhatter posted two blogs related to Yeeloong's status. I guess I should say something too.

First of all, I recommend this mailing list http://groups.google.com/group/loongson-dev to those who want to know the latest news about Loongson. If you want to try Gentoo on Yeeloong, you can take this http://www.gentoo-cn.org/~zhangle/loongson_mips3_n32_mplt_20081231.tar.bz2 The file's sha256sum is c94bcd45e58e5f4b8314942a6b3110a2316fd74adb009c8269d1e8e2077d7c72. Please note the userland is N32 ABI, meaning there may be more problems than in O32. But I should've already solved many of them for you.

I have been working on Fuloong 2E/2F and Yeeloong's support, particularly N32 ABI system. Firefox is just one example.

I have 3 Loongson machines, all donated by lemote:

One Fuloong 2E box. Now gentoo-cn.org is running on it. O32 ABI userland. Gcc 4.4, -march=loongson2e. MIPS plt. I am not running X on it. I am not sure if Redhatter runs X on it or not. If not, then you can say that Fuloong 2E has not X support in Gentoo. Anyway, I think very few people have it, and even fewer are using it as desktop.
One Fuloong 2F box. I have two Gentoo on it. One O32 ABI userland, the other is N32 ABI userland. Gcc 4.4, -march=loongson2f. MIPS plt. xorg-server-1.6.2. LXDE. Dev machine.
One Yeeloong notebook. I have one Gentoo on it. N32 ABI userland. xorg-server-1.6.2. xf86-video-siliconmotion-1.7.2. LXDE. Dev machine.

For the kernel support, please just use this kernel source, all you want is just there: http://groups.google.com/group/loongson-dev/browse_thread/thread/1b0a6a4f7c2485e8 You don't need to have gcc 4.4 if you don't care about -march=loongons2f. There is some magic in the Makefile which could make the compiling just work. And in this source, as option -mfix-ls2f-kernel is not enabled. So that binutils patch is not required for this source to compile. And this patch solves the problem that system sometimes hangs under stress test. So if your system never hang before, then maybe you don't need it.

For firefox, upstream xulrunner 1.9.1 already has O32 ABI patch. So nothing extra need to be done if you want to run Firefox in O32 ABI userland. Just emerge. If you are using N32 ABI userland, please use the ebuild from my overlay, check the link at the top. I haven't tried thunderbird though. I am now using Mutt anyway, :D.

For X, it is quite complicated. You can claim that X server now requires no patch at all, but that actually depends on which machine and which version of xorg-server you are using. On Fuloong 2F, xorg-server-1.6.2 does not need patching, the driver I am using now is the highest version of xf86-video-sis in tree. On Yeeloong, xorg-server-1.6.2 need patching if you use xf86-video-siliconmotion-1.7.2 from xorg (I have a live ebuild for it in my overlay). If you use xorg-server-1.4.x, you can also use xf86-video-siliconmotion-2.2.8 (I will explain it immediately) from lemote, this way xorg-server does not need patching. BTW, this xf86-video-siliconmotion-2.2.8 is actually from siliconmotion card's manufacturer, it should be based on xorg's xf86-video-siliconmotion somewhere before it has got libpciaccess support and later it has got its own version numbering scheme. So this xf86-video-siliconmotion-2.2.8 won't work on xorg-server-1.5.x and later. And I have tried to add libpciaccess support to it, but after done what I think is necessary, I found there are more problems. So I gave up on xf86-video-siliconmotion-2.2.8. I left the sources here: http://www.gentoo-cn.org/gitweb/?p=siliconmotion.git;a=summary Then I tried to fix xorg's siliconmotion driver, and I found the cause http://bugs.freedesktop.org/show_bug.cgi?id=21528. So now xf86-video-siliconmotion-1.7.2 is working on Yeeloong without any patch, only if you use 24 bit depth. If you use 16 bit depth which is required for dual head mode, there are still problems. http://bugs.freedesktop.org/show_bug.cgi?id=21622 Also there maybe some configuration options are needed in xorg.conf for X to work, so please check out my xorg.conf on fuloong2f and yeeloong.

MIPS N32 firefox 3.5 beta4

2009-05-04T15:37:00.011+08:00

It is working too. The xulrunner's ebuild is already in loongson overlay. For the mozilla-firefox ebuild, just use the one from mozilla overlay.

If you experienced segfault, try to re-emerge sqlite with no optimization. Using the bundled sqlite surely is not an optimal solution, ;)

One more thing: Xorg's siliconmotion driver is now working on yeeloong notebook: http://bugs.freedesktop.org/show_bug.cgi?id=21528

MIPS N32 firefox in acid3 test

2009-04-30T16:37:00.007+08:00

My quest for MIPS N32 firefox could finally come to an end, since I just got it scores the same as X86 firefox.

Remember I said it would encounter bus error on a few websites in my last related post. But I didn't plan to look into this issue before dealing with cache aliasing problem.

However, since Rayson Ho helped me to locate the exact cause of this issue, I decided to finish it first.

The problem is caused by unaligned access of ldc1/sdc1 instruction. These two instructions' operand must be 8 bytes aligned. But when crashing, the operand is only 4 bytes aligned.

After some discussion and experimenting, I found a workaround for sina.com.cn crashing problem. Yeah, a padding pointer sounds scary and fragile, but it did work. Before posting any comment to this, please make sure you have read all the emails in that thread.

Then Fai Wong reported to me that it still crash in acid3 test. So I took another look. This time the problem happened in a different location, and it is harder to solve. Because the object in question sometimes is 8 bytes aligned, but sometimes it is only 4 bytes aligned, which does not make any sense, since the object contains double variable. So, either way, the double variable just can't get aligned in both case. I thought of kernel exception handler. I did come up with a patch and it worked! But since Ralf refused to accept it, I had to move on. And I found the reason is because of the way the memory is allocated - placement new. Thanks to LI Daobing for telling me this. And this is what the final patch looks like.

Ftrace is working now on my loongson box

2009-04-14T22:24:00.005+08:00

http://www.linux-mips.org/archives/linux-mips/2009-04/msg00112.html

So I confirmed that this MIPS ftrace support is really working. Thanks to Wu Zhangjin (吴章金). However, I have no interest in finding out what kind of difference between my loongson2f patch and wu's caused wu's ftrace patch does not work on top of my loongson 2f patch. What I would like to see now is to get loongson2f patch merged into mainline.

Plus, I wish I could make loongson linux to be able to use 4k page(Now, loongson could only use 16k page in order to avoid d-cache aliasing). I have already started working on it now. Even if it turns out that I can't, I could tell others what I have done in order to achieve this goal. And by that time, I would've got a much deeper understanding of Linux's memory management subsystem.

Two more kernel patches

2009-03-17T00:28:00.005+08:00

This one is MIPS related, already accepted:
MIPS: Fix TIF_32BIT undefined problem when seccomp is disabled

This one is proc filesystem related:
[PATCH] filp->f_pos not correctly updated in proc_task_readdir

The later one is also MIPS related actually, in a peculiar way:
MIPS N32 does not have getdents64 system call. And because of readdir's implementation in glibc, this bug will be triggered when trying to run pstree or simply 'ls /proc/xxxx/task', where xxxx is the pid of a multithread process.

Firefox for MIPS N32 ABI

2009-03-12T02:40:00.013+08:00

Finally, I could announce that it is working (tm).
I just submitted the patches (together with O32 ABI patch) to upstream.
https://bugzilla.mozilla.org/show_bug.cgi?id=482759

This is a big step forward for MIPS N32 GNU/Linux desktop.

One thing to note though: It (the N32 one) would encounter bus error on a few websites, e.g. www.sina.com.cn. I will try to find out why later when I have time.

For those who are into long stories, please read on:

I finally sorted out the font size problem, independently. It turned out that the problem is caused by strict aliasing issue in NSPR (NetScape Portable Runtime). Specifically, when parsing css file, in order to get the font size, PR_strtod() will be used to convert string to floating point value. But because of the strict aliasing issue, certain code in PR_strtod will be optimized out if -fstrict-aliasing is turned on, which is just the case if -O2 is used. And as a result, the floating point value would be wrong， e.g. "1.5" will be converted to 15.0, "0.67" will become 67.0. At first, I thought it was a bug in gcc 4.4 (not released yet, but supports -march=loongson2f), since this problem does not exist if I used gcc 4.3. So I filed a gcc bug [1]. However, as Jakub Jelinek stated, this is actually a bug in NSPR [2].

PS: flameeyes just reminded me that this is not a problem of NSPR its own [3]. He is trying to find out all the packages that have used this dtoa.c. The list is not finished yet. But there is one thing for sure, there will be quite a few.

[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39418
[2] https://bugzilla.redhat.com/show_bug.cgi?id=487844
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518927

mips64el-unknown-linux-gnu cross toolchain building

2009-02-25T16:15:00.019+08:00

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 investigate.

To use it, just run the following commands:

cd
git clone git://www.gentoo-cn.org/var/git/loongson.git
mkdir cross-overlay
cd cross-overlay
mkdir profiles
echo 'cross-overlay' > profiles/repo_name
ln -sf ../loongson/sys-libs
sed -i -e '/PORTDIR_OVERLAY/ s/"$/ ${HOME}\/cross-overlay"/' /etc/make.conf
crossdev -t mips64el-unknown-linux-gnu --b 9999 --g 4.4.0_pre9999 --l 2.9_p20081201-r2 --k 2.6.27-r2 -v

MIPS N32 patch for xulrunner(firefox)

2009-01-14T23:38:00.004+08:00

Finally, I have produced some results. I have watched 6 seasons of 24 and 2 seasons of Friends since late last month. So this is delayed. :P
The patch is here.
I think it still need some tweaks, you can always get the latest patch in my loongson overlay on http://www.gentoo-cn.org/gitweb.

The produced xulrunner could run a little example:
http://dev.gentoo.org/~r0bertz/xulrunner/myapp.tar.bz2
(untar the tarball, cd myapp && xulrunner-1.9 application.ini)

However, I haven't got a fully functioning firefox yet.
Some font size is extremely large. And sometimes bus error.

I have noticed that I have used -O3 to compile it.
I will try -O2/-O1 later and see if it still bus error.

glibc doesn't build with linux-header-2.6.28 on loongson

2008-12-28T18:09:00.012+08:00

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 solved, or any userland program including kernel headers which include {asm,linux}/byteorder.h will fail to build, e.g. glibc.

It seems to me that the most straight forward way, but also very intrusive way is to make the handling of these two marco consistent in the two projects. That'll be a very large changeset. Also it will suddenly change a convention in a project that has already been followed for a long time. So I don't think people will accept this.

How this problem will be solved is still remained to be seen.

EDIT: someone reported that it worked well on ~amd64. So I modified the title and removed the last sentence. I will see if this problem still exists on my x86 notebook.

EDIT 2: I confirm that this problem does not exists on x86. I will find out what exactly is going on loongson, or rather mips. :)