Friday, March 30, 2007

loongson specific profile

If loongson finally were officially supported by gentoo, it must have
its own profile.
Currently, it uses cobalt's profile. Of course, one has to do some
dirty hacks to make it usable with loongson. For example, cheat
portage to make it think colo is already installed. Loongson box uses
pmon as bios and bootloader, doesn't use colo which is cobalt's
Recently, I have read PMS draft. For me, it is quite informative. I've
learned some internals about our package manager, specifically I've
learned something about profile which i don't know before.
Then I applied those knowledge into reality.
I created a loongson specific profile in loongson overlay and used it.
The main trick here is to write absolute path of parent directory into
PARENT file, instead of "..". And it turned out to work well.

Loongson got license from MIPS Technologies
How exciting!!!

Monday, March 26, 2007

Loongson Gentoo stage 4

I have uploaded a stage4 to,
under the directory of Gentoo.
FEATURES include but not limited to:
1. nptl pthread library, the debian shipped with box uses Linuxthreads
pthread library.
2. complete KDE 3.5.5
3. 4 kernels, 32bit/64bit, with/without kgdb
4. partial mirror of, include half-translated Simplifid
Chinese handbook
5. firefox, mplayer, audacious...
I used binutils-2.17 when compiling firefox, USE flag of binutils is
"multislot -multitarget nls -test -vanilla"
This mplayer doesn't contain any loongson specific patch, but it works.

Friday, March 23, 2007

Gentoo 2007.0 livecd will have Simplified Chinese interface

The relevant thread on Gentoo China google group

Monday, March 19, 2007


目前只支持IRIX和n32 ABI
现在龙芯还只能运行于Linux,Linux上的应用程序主要还是用o32 ABI
The problem with n32 though, is that few applications actually handle
this case well. Debugging tools like strace and gdb are not coded to
handle this... KDE works sort-of, but is broken in several key areas.
Gnome is totally useless on n32.
两个解决方案,一个是multilib,一个是移植到o32 ABI。似乎都不太容易。
you'll need your userland CHOST set to mips64 instead of mips, a gcc
and binutils capable of handling all the binary formats you want to
use, and appropriate system libraries for all the ABIs
The optimal solution would be multilib, however the necessary code for
Portage has not been written. Architectures like AMD64 work because
of shear ugly kludges ... the actual multilib case isn't handled at
一是增加一个汇编文件mipsel.s(SGI的mips是大头端的,龙芯是小头端),改成o32 ABI
二是为asm generator增加mipsel+o32后端

KDE on loongson


Labels: , ,

Friday, March 16, 2007

Redhatter has released mips1(little endian) stages
They should work on loongson, however i haven't tried it yet.
I will soon release a stage4 for loongson, including KDE.
Stay tuned.

Thursday, March 15, 2007

representative of the Gentoo community

Remember, the moment you participate in a public discussion on the
Gentoo fora, you have made yourself a representative of the Gentoo

Every gentoo user/dev should read this:

Wednesday, March 14, 2007



Friday, March 09, 2007

Gentoo Etiquette Policy

Thursday, March 08, 2007

Re: [RFC]possible improvements to --with-sysroot

On 3/6/07, Daniel Jacobowitz <> wrote:
> On Tue, Mar 06, 2007 at 02:05:06AM +0800, Zhang Le wrote:
> > I have used "strace -f" to check where linker looked for -lqt-mt. From
> > what I have observed, it seems that ld didn't use
> > $SYSROOT/etc/
> Well, it's supposed to, so I suggest you check what's happened in ld.
I found a clue which may lead to a neat solution to this problem. And
this has something to do with gcc, so I still posted it here.
First of all, $SYSROOT/etc/ solution maybe an overkill, so I
think we can ignore it for now.
The finding is if ld is invoked with --sysroot option and if the dir
specified by -L has a leading "=", for example:
--sysroot=/usr/mipsel-unknown-linux-gnu -L=/usr/qt/3/lib -L/usr/lib -lqt-mt
Then when ld will looking for in
/usr/mipsel-unknown-linux-gnu/usr/qt/3/lib, instead of /usr/qt/3/lib.
Thus problem solved.
So I am wondering if there is a way to detect whether gcc is doing cross
compile. If so, when cross compiling is detected, collect2 search for
-L option in COLLECT_GCC_OPTIONS, and insert a "=" between -L and the
actual path.
I think this way is better than the $SYSROOT/etc/ way.

Zhang Le, Robert
Linux Engineer/Trainer

Labels: , , ,

Monday, March 05, 2007

videos from fosdem

FOSDEM means Free and Open source Software Developers' European Meeting

Daniel has left again

This is what he said:
Gentoo is only going to be fun and productive again if we:

1) maintain a courteous and professional atmosphere
2) focus on good, transparent project management and collaboration
3) deliver cool technologies to Gentoo users

AND IN THAT ORDER ONLY, which is the only order that works long-term.
It makes no sense to try to do this in reverse order. It does not
work. 3 requires 2 and 2 requires 1. Right now these three pillars are
being treated as mutually exclusive goals which is absolutely
ridiculous and wrong, where we accept failure in point 1 in the hope
of achieving 3.

没有键盘鼠标的是client,执行synergyc serverip
$ cat /etc/synergy.conf
# sample synergy configuration file
# comments begin with the # character and continue to the end of
# line. comments may appear anywhere the syntax permits.

section: screens
# three hosts named: moe, larry, and curly

section: links
down = adriano
up = loongson

section: options
switchDelay = 500

Sunday, March 04, 2007


Distcc is working.
Howerver, I didn't get it working at the beginning.
Because I am curious about what messages distccd's pass between
themselves. So I fired up wireshark, then I go to sleep.
As you would expect, eventually wireshark occupied all free space on
/tmp which is also used by distcc to produce object files. And as a
consequence, distcc failed.
Originally, the distcc run with "--log-level critical", so it sent
nothing to syslog.
By using this command, you can see what distcc is doing in real time:
distccd --verbose --log-stderr --daemon --user distcc --allow --no-detach

Saturday, March 03, 2007

I will give up cross compiling KDE

Two posts related to this decision:

I will try distcc.

some ideas about DEPEND/RDEPEND

(zhllg) Is it possible that a runtime dependency is not a build time dependency? or could a package be built without some package, but require it in order to run?
(igli) yes
(zhllg) igli, any example?
(igli) not necessarily required at run time; in any case eg an app that runs a cmd
(igli) might not need to be built against the other app
(zhllg) oh that is true
(igli) synfig has run time deps for i think jpeg and stuff
(igli) need to work on ebuild.. :(
(zhllg) igli, what about the runtime dependency is a library
(igli) usu if it's a dep against a lib, it's compile time
(marienz) both.
(igli) depends on whether it looks for the .h files
(marienz) normally both.
(igli) oh sorry, yes runtime as well of course
(igli) as lib needed on system when app is running :) doh!
(zhllg) then IMHO maybe in that case just specify the dependency in RDEPEND is enough, what do you think?
(marienz) you normally need the lib present at build time or the link will fail.
(zhllg) yes
(igli) yup
(igli) zhllg: if only RDEPEND that means the app is not usually linked as it would be with a library
(igli) library depend is usually compile time as the app will call the lib code
(igli) not the same as say running a cmd
(zhllg) actually i am not quite sure about the implication of DEPEND, if not speficy the dep in DEPEND, will the dep be merged before the dependent ?
(igli) eg rdepend on pci-utils or something
(me22) many perl scripts don't need any building, but will need packages or commands to run
(igli) zhllg: if not specified, not a dep
(zhllg) igli, i mean just specify it in RDEPEND
(zhllg) not DEPEND
(igli) ok then not necessarily
(zhllg) igli, you mean in that case dep maybe absent when emerging the dependent?
(igli) yeah might be emerged just after as it's not required for building the pkg
(igli) if it were would be a compile time dep (ie in DEPEND)
(marienz) zhllg: it will normally be merged early enough even if it's just in RDEPEND but this is not guaranteed.
(marienz) zhllg: if you need it at build time you should put it in DEPEND too.
(zhllg) marienz, actually today i encountered a problem that rare people will come across
(zhllg) i try cross compile kde using xmerge script
(zhllg) the host system has modular kde installed
(igli) omg
(zhllg) i want to install non-modular kde in target system
(marienz) why am I not surprised that doesn't actually work
(zhllg) however, conflicts occurred
* Fedman ( has joined #gentoo-dev-help
(marienz) the ebuild format is not advanced enough to properly deal with cases like this.
(igli) i need someone to test an update script :)
(marienz) the problem is probably related to the fact that you tend to need some of the DEPENDS on the build system, not the target.
(zhllg) the cause of the conflict is emerge want to install kdebase and the like in my host system
(marienz) (think autoconf / automake deps)
(marienz) nod.
(igli) zhllg: you can't do it without the same sort of setup on both
(zhllg) as kdebase is listed as a DEPEND
(marienz) I think to work around this we need to split DEPEND up into hostdepends and builddepends
(marienz) if you know what I mean.
(zhllg) igli, actually i have setup an overlay
(zhllg) and it works now, i want to see if the cross compile would succeed
(marienz) well, those words I use make no sense, but I think you get the general idea :)
(igli) what's that got to do with it?
(marienz) the problem is this requires changing all the ebuilds and is hard to get right if you don't crosscompile everything to test :)
marienz me22 masterdriverz mzbot mjolnir40k mpagano mren
(igli) marienz: i knew what you meant but it seems wrong written down
(marienz) it does?
(zhllg) marienz, that sounds like a good idea
(igli) host depends seems like rdeps
(marienz) yeah, I didn't quite use the right words
(igli) well deps for the machine which will install the pkg
(marienz) build-time deps that are run on the build system vs build-time deps that are linked against (need to be present in the target system)
(igli) deps for the machine which will install the pkg cover it?
(marienz) you'd end up with three kinds of deps
(marienz) buildtime deps for the build system, buildtime for the target system, runtime (for the target system)
(marienz) I think.
(igli) i don;t :P
(igli) buildtime for target makes no sense; pkg is already built
(marienz) err
(marienz) no?
(marienz) *buildtime* for target. At that time the package is obviously not built yet, or it wouldn't be buildtime
(marienz) (these deps would be libraries that are linked in)
(igli) what's the build system do then?
(marienz) buildtime target dep: dev-libs/blah
(marienz) buildtime host dep: autoconf/automake/etc
(marienz) s/host/buildsystem/
(zhllg) or, we specify that DEPEND is disjoint from RDEPEND, categorize libs as RDEPEND, and require all RDEPEND be emerged before the dependent
(marienz) that'd be a bad idea since RDEPEND is useful to avoid circular deps.
(zhllg) oops
(marienz) and to avoid pulling in unneeded deps at build time.
(igli) yeah well buildtime target dep: dev-libs/blah seems same as redepend
(zhllg) or, splite RDEPEND, libs and non-libs(those need to be system()ed)
(igli) what for?
(zhllg) avoid circular dep? could achieve that?
(zhllg) i am not sure, just an idea
(igli) can't see it; you appear to be talking about rdepends
(zhllg) yeah, "(zhllg) or, splite RDEPEND"
(igli) sorry the prior conversation about target deps was effectively rdepends
* zzam (n=zzam@gentoo/developer/zzam) has joined #gentoo-dev-help
* ChanServ gives channel operator status to zzam
* Jell-O-Fishi ( has joined #gentoo-dev-help
(zhllg) i agree
(zhllg) so i suggest to splite RDEPEND into two RDEDENDs, libs(target deps in your word), and non-libs

[RFC]possible improvements to --with-sysroot

The following suggestion is based on my understanding of
--with-sysroot, if there were any error, please correct me.
To my understanding, currently if cross-compile tool chain (including
gcc) is configured with --with-sysroot when installing them, then when
cross compiling, ld will look for libraries in $SYSROOT/usr/lib and
Wouldn't it be great that we go one step further that we let ld look
for libraries in the dir listed in $SYSROOT/etc/, if this
file ever exits? Of course for each entry in $SYSROOT/etc/,
we prefix $SYSROOT to it.
Comments are welcomed.

Zhang Le, Robert

This is an email I have posted to gcc mailing list.

Thursday, March 01, 2007

emerging KDE on loongson

I have got DRI working in Gentoo on loongson.
mesa/libdrm/kernel/xorg-server/xf86-video-ati need to be patched in
order to achieve this.
I have set up a loongson overlay, including the necessary patches.
Get it here:

Labels: , ,