From: Andreas Schwab <schwab@suse.de> Date: Thu, 22 May 2008 18:32:29 +0200GLIBC is overly flexible, to the point of being painful. It is designed in such a way that you cannot even do a fully parallel build. It can only parallelize in one directory at a time. It stats files like crazy, in every subdirectory it visits, in order to implement this prioritization scheme. It is the most inefficient build system that I am aware of for such an important code base. --
| Stephen Smalley | Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Jan Engelhardt | intel iommu (Re: -mm merge plans for 2.6.23) |
| Greg Kroah-Hartman | [PATCH 005/196] Chinese: add translation of SubmittingDrivers |
git: | |
| David Fenyes | sigsetmask()? (LINUX) |
| Stephen Tweedie | Unmounting root (no kidding!) [was: Some Linux problems---solved] |
| Les Andrzejewski | X386/WD90C31/SUMSUNG SYNC MASTER 4 |
| Doug Evans | Re: Stabilizing Linux |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Linus Torvalds | Re: [GIT]: Networking |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Herbert Xu | Re: [PATCH] myr10ge: again fix lro_gen_skb() alignment |
