coreutils has an "unlink" for /confdir3 Which breaks sandbox on my system. Reproducible: Always Steps to Reproduce:
i can reproduce this too. there is something with glibc that truncates the first terms of of ${PORTAGE_TMPDIR} out of the path name. i don't know what a clean fix is, or whether that is a bug with either glibc or the configure script.
can someone paste or give an analysis so we can send a bug report upstream? alastair?
well, it looks more like a sandbox problem now. attached is the offending code, to reproduce: gcc -o testdir test.c SANDBOX_WRITE=/var/tmp/portage:/dev /usr/lib/portage/bin/sandbox ./testdir i think maybe unlink is the one that can't accept a larger pathname than PATH_MAX btw, for reference, it dies on the line: checking whether getcwd properly handles paths longer than PATH_MAX... checking whether getcwd is declared... yes
Created attachment 12472 [details] test.c test case that breaks sandbox
Az, looks like a sandbox issue
sandbox relies heavily on getcwd to function. This configure script is testing if getcwd works for huge paths by create a huge path and running getcwd on it... checking whether getcwd properly handles paths longer than PATH_MAX... checking whether getcwd is declared... yes no getcwd DOES NOT properly handle paths longer than PATH_MAX on my system. It's returning '/jrray/tmp/sandbox/confdir3/confdir3/confdir3/conf...' instead of '/home/jrray/tmp/sandbox/confdir3/confdir3/confdir3/conf...' You can see this for yourself if you patch the test.c to look like: if ((len = strlen (c)) != cwd_len) { + fprintf(stderr, "length mismatch\n'%s'\n", c); fail = 1; break; } Without a working getcwd, it is impossible to make sandbox survive this test. But if getcwd worked, this test would be irrelevent. Looks to me that this package will need to disable sandbox. - Robert
I ran into a similar problem when experimenting with long paths a while ago. Turned out this is a limitation of the `getcwd' syscall, which allocates a single page, puts the current directory name at the end of it, then walks up the tree until either it reaches the root, or the current directory name doesn't fit into the remaining space; then copies the result to userspace. So no matter how big the passed in buffer is, the limit is the platform's page size (4K on x86). Using "/proc/self/pwd", which internally depends on getcwd, won't work either. Didn't look into 2.5.x kernels yet, but here are my test functions: --- #include <sys/syscall.h> char *getcwd_s(char *buf, size_t size) { long rv = syscall(SYS_getcwd, buf, size); if(rv < 0) return (errno = -rv, NULL); return buf; } char *getcwd_p(char *buf, size_t size) { /* readlink does not append '\0' */ memset(buf, 0, size); if(readlink("/proc/self/cwd", buf, size-1) < 0) return NULL; return buf; } /* #define getcwd getcwd_s /*-*/ /* #define getcwd getcwd_p /*-*/ --- One solution would be to add glibc's generic getcwd (in sysdeps/posix) to sandbox. The version I was using back then (glibc-2.1) had a minor bug in it though (when a certain depth was reached and it had to enlarge `dotlist', it didn't put a '/' between the old and the new part) which always made it abort with ENOENT at depth 76. With that fixed, however, it works for any length/depth paths (although a lot slower than the syscall). Another problem is with the test program itself; the result buffer is declared as `char buf[PATH_MAX+20]' (PATH_MAX is 4096 and gets pulled in from <linux/limits.h>), but the call is made as `getcwd(buf, PATH_MAX)', which would fail with longer paths even if getcwd() could handle them. Changing the second call to `getcwd(buf, PATH_MAX+19)', the test succeeded for me with the generic getcwd().
Created attachment 13694 [details, diff] sandbox-PATH_MAX-fix.patch 22 Jun 2003; Martin Schlemmer <azarah@gentoo.org> libsandbox.c, canonicalize.c create-localdecls : When checking path names of files accessed, we need to canonicalize it, else it may be a symlink in a 'write allowed' directory pointing to a file in a directory we should not have write access to. With something like coreutils-5.0, we have two problems: 1) One of the tests checks if getcwd() can return a path longer than PATH_MAX. This test then tries to create a dir which even while created local (mkdir("conftest2")), it ends up being resolved with a name that is much larger than PATH_MAX. The problem now is that canonicalize() have undefined behaviour when the path was too long (returned wrongly truncated paths, etc), and pass the wrong path to before_syscall() (causing the bogus sandbox violations). 2) The ecanonicalize() function we used, along with the canonicalize() function did not support longer than PATH_MAX. This is partly a cause for 1), but the error checking (rather lack of it) of calls to erealpath() in canonicalize() was the prime reason for 1). As we do not use this canonicalized name to call the function, we resolve this by fixing canonicalize() to do better error checking, and ecanonicalize() as well as all functions in libsandbox.c to use a PATH_MAX of 'PATH_MAX * 2'. While they will resolve paths properly now, and can check if a write/read is allowed, the functions called from the sandboxed environment will still work as expected. This should resolve bug #21766.
Nick, I applied sandbox changes to CVS. Could we get a new portage out?
Will be fixed when portage-2.0.48-r2(3?) is unmasked.
FYI, I received the following: make[2]: Leaving directory `/var/tmp/portage/coreutils-5.0/work/coreutils-5.0' make[1]: Leaving directory `/var/tmp/portage/coreutils-5.0/work/coreutils-5.0' --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-coreutils-5.0-13562.log" unlink: /confdir3 -------------------------------------------------------------------------------- Today on both a SPARC box running ~sparc, and an x86 running stable. It prevented compilation of coreutils and the rest of emerge world. ultra60 gentoo # emerge -s portage Searching... [ Results for search key : portage ] [ Applications found : 3 ] (snip) * sys-apps/portage Latest version available: 2.0.48-r1 Latest version installed: 2.0.48-r1 Size of downloaded files: 191 kB Homepage: http://www.gentoo.org Description: Portage ports system
FYI read comment #10
reopening -- this seems to affect portage -r5 and -r7 as well
hey folks, i use portage 2.0.48-r7 now and coreutils still refuse to be emerged (with -r5 too), i told this naz and seemant already and they suggest to paste the errors here, so here we go: --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-coreutils-5.0-17107.log" unlink: /portage/portage/coreutils-5.0/work/coreutils-5.0/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confd and so on and so on, emerge info is: Portage 2.0.48-r7 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r1) ================================================================= System uname: 2.4.20-gentoo-r5 i686 AMD Athlon(tm) processor GENTOO_MIRRORS="ftp://gentoo.linux.no/pub/gentoo/ http://gentoo.inode.at/ http://ftp.easynet.nl/mirror/gentoo/ ftp://ftp.easynet.nl/mirror/gentoo/ ftp://gentoo.inode.at/source/" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/scratch/portage" PORTDIR_OVERLAY="/usr/local/portage" USE="x86 oss 3dnow apm avi crypt cups encode foomaticdb gif jpeg libg++ mad mikmod mmx mpeg ncurses nls pdflib png quicktime spell truetype xml2 xmms xv zlib gdbm berkdb slang readline arts tetex svga tcltk java guile ruby mysql X sdl gpm tcpd pam libwww ssl perl python esd imlib oggvorbis gnome gtk qt kde motif opengl mozilla cdr aalib acpi fbcon imap gtk2" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-O3 -mcpu=athlon-tbird -march=i686 -DHAVE_ERRNO_AS_DEFINE=1 -pipe" CXXFLAGS="-O3 -mcpu=athlon-tbird -march=i686 -DHAVE_ERRNO_AS_DEFINE=1 -pipe" ACCEPT_KEYWORDS="x86 ~x86" MAKEOPTS="-j8" AUTOCLEAN="yes" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" FEATURES="sandbox ccache distcc" any suggestions? regards, mathias
I have a fait idea that this goes deeper than I thought. It works fine on my dev box, but on my box at work, it does not. Looking into it ....
I think the answer is in comment #6 and comment #7... Even with standard locations, the testprog tries to unlink /tmp/portage/coreutils-5.0/work/coreutils-5.0/confdir3/confdir3/.... instead of /var/tmp/portage/coreutils-5.0/work/coreutils-5.0/confdir3/confdir3/....
Just noticed... If PORTAGE_TMPDIR is not /var/tmp and the access violation occurs, sandbox crashes because the buffer that is used to print the violation is way to small too hold a path this long!
Yes, I fixed the crash. Anyhow, it works fine with a 2.5/2.6 kernel, but not with a 2.4 one it seems. And getting getcwd to work without using a system call, you need stat (lstat() actually), but for that I still need a system call, so guess will have to add a hack rather.
Created attachment 15076 [details, diff] sandbox-getcwd-fix.patch As my systems had 2.5 kernel, the getcwd system call handled strings larger than PATH_MAX (bug #21766). It however does not work the same on 2.4 kernels. To fix, I added the posix implementation of getcwd() (from glibc cvs) that do not need the system call. We use the default getcwd() function via a wrapper (egetcwd), and then lstat the returned path. If lstat fails, it means the current directory was removed, OR that the the system call for getcwd failed (curious is that it do not fail and return NULL or set errno, but rather just truncate the retured directory - usually from the start), and if so, we use the generic getcwd() function (__egetcwd). Note that we do not use the generic version all the time, as it calls lstat() a great number of times, and performance degrade much. Note that the patch do include some formatting changes, so it might be hard to see the real fix.
Anyhow, its commited to CVS, so new version of portage should fix this.
Nick, just hang on before you may do a new rev - I need to check in one more fix.
Ok, fixed another small but possible fatal bug - Nick, should be fine now for new portage.
I get the following sandbox violation (looks very odd): unlink: /portage/coreutils-5.0-r1/work/coreutils-5.0/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3
Yes, you will if you do not have the latest CVS sandbox code (Note, not in any portage yet ... ).
I'm having this problem now (I already have coreutils-5.0 installed; the failure is in trying to upgrade to 5.0-r1) [portage-2.0.48-r7] phil
Ditto, nice error: unlink: /portage/coreutils-5.0-r1/work/coreutils-5.0/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3 That's an odd one for sure.
Again, it is fixed in sandbox CVS, but is not yet released in a portage version. For now, do: # FEATURES="-sandbox" emerge coreutils Thanks.
*** Bug 25484 has been marked as a duplicate of this bug. ***
It's in 2.0.49_pre17
Hmmm. doing: FEATURES="-sandbox" emerge coreutils doesn't seem to work. I still get a sandbox violation for the monster unlink. Any other suggestions?
*** Bug 25702 has been marked as a duplicate of this bug. ***
# FEATURES="-sandbox -usersandbox" emerge coreutils Btw, latest 2.0.49 have the new sandbox.
I might have fixed this bug today. I didn't realize bug 25702 was a duplicate of this one. Anyway, the configure script tests for a glibc bug, then tries to clean up after itself. Easiest thing to do is short-circuit the cleanup since it's unnecessary (and error-prone as we've found out). Take a look at files/coreutils-5.0-confdir3.patch if you're interested in the fix. I suspect it will continue to apply (maybe with some minor massaging) to newer versions of coreutils. Since you guys have been looking at this for a while, I'll leave this bug open until you decide whether you like or don't like my fix. You can close it when you like.
Nice to see it works now. :)
I have thought about that fix as well Aron, but it will not fix the main issue, which is sandbox should not be limited by PATH_MAX, or rather, it should be able to handle if it have to resolve a path and in doing so, it should be able to handle PATH_MAX + 20 or PATH_MAX * 2 or whatever. Can you guys please try the latest sandbox code without the confdir3 patch ? Thanks.
*** Bug 24951 has been marked as a duplicate of this bug. ***
*** Bug 26037 has been marked as a duplicate of this bug. ***
Should be fixed with portage-2.0.49+.
I'm not sure if I've got something strange going on because of my particular setup (Portage on a Redhat system), but I'm getting this same issue on coreutils-5.2.1-r4 Following is what is what I receive when trying to emerge coreutils: --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-sys-apps_-_coreutils-5.2.1-r4-26688.log" unlink: /confdir3 -------------------------------------------------------------------------------- My portage version is: Portage 2.0.51-r15 (default-linux/x86/2004.2/gcc34, gcc-3.3.5, unavailable, 2.4.20-021stab022.11.777-enterprise i686) ================================================================= System uname: 2.4.20-021stab022.11.777-enterprise i686 i686 Unknown Host Operating System Python: dev-lang/python-2.3.4-r1 [2.3.4 (#1, Mar 1 2005, 03:03:21)] ccache version 2.3 [enabled] dev-lang/python: 2.3.4-r1 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.9.4, 1.5, 1.8.5-r3, 1.6.3, 1.7.9-r1, 1.4_p6 sys-devel/binutils: 2.15.92.0.2-r1 sys-devel/libtool: 1.5.10-r4 virtual/os-headers: [Not Present] ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -mcpu=i686 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -mcpu=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 apache2 berkdb bitmap-fonts ccache crypt curl emboss f77 font-server fortran gd gdbm gif imap imlib ipv6 jpeg libg++ libwww mad maildir mysql ncurses nls nptl pam pdflib perl png python readline sasl slang spell ssl svga tcpd tiff truetype-fonts type1-fonts xml2 zlib" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, PORTDIR_OVERLAY