On Thu, Apr 26, 2012 at 2:26 PM, Michael Mol <mike...@gmail.com> wrote: > On Thu, Apr 26, 2012 at 2:20 PM, Canek Peláez Valdés <can...@gmail.com> wrote: >> On Thu, Apr 26, 2012 at 11:53 AM, Michael Mol <mike...@gmail.com> wrote: >>> On Thu, Apr 26, 2012 at 11:27 AM, Mark Knecht <markkne...@gmail.com> wrote: >>>> On Thu, Apr 26, 2012 at 7:41 AM, Michael Mol <mike...@gmail.com> wrote: >>>>> On Thu, Apr 26, 2012 at 10:34 AM, Qian Qiao <qian.q...@gmail.com> wrote: >>>>>> On Thu, Apr 26, 2012 at 19:40, Michael Mol <mike...@gmail.com> wrote: >>>>>>> >>>>>>> MAKEOPTS="-j1" didn't fix it. Off to find another solution. >>>>>>> -- >>>>>>> :wq >>>>>>> >>>>>> >>>>>> Does sound like it's just you. I've been running with MAKEOPTS="-j13" >>>>>> and everything compiled and ran just fine. >>>>> >>>>> Checking to see if it's a distcc problem, now. If it is, it'll only be >>>>> the third time I've ever had issues from distcc, and the first time a >>>>> distcc issue resulted in a successful build of a package that broke >>>>> things. >>>>> >>>>> -- >>>>> :wq >>>>> >>>> >>>> Late to the party as I've been travelling. Running glibc-2.14.1-r3 >>>> here with no problems. >>>> >>>> For the i7 i980x here's my make.conf stuff >>>> >>>> FEATURES="buildpkg" >>>> >>>> EMERGE_DEFAULT_OPTS="--with-bdeps=y --jobs=5" >>>> MAKEOPTS="-j13 -l8" >>>> PORTAGE_NICENESS=5 >>>> PORTAGE_IONICE_COMMAND="ionice -c 3 -p \${PID}" >>>> >>>> This machine is mostly stable. >>> >>> For comparison, here's the current setup on my Phenom 9650: >>> >>> #expanded form of -march=native. Nothing special here. Noting this >>> here because people keep freaking out when they see it in-line. >>> SYS_CFLAGS_MARCH_NATIVE_EXP="-march=amdfam10 -mcx16 -msahf -mpopcnt >>> --param l1-cache-size=64 --param l1-cache-line-size=64 --param >>> l2-cache-size=512 -mtune=amdfam10" >>> CFLAGS="${SYS_CFLAGS_MARCH_NATIVE_EXP} -O2 -pipe -ggdb3" >>> CXXFLAGS="${CFLAGS}" >>> FEATURES="splitdebug" >>> MAKEOPTS="--jobs --load=5" >>> EMERGE_DEFAULT_OPTS="--jobs --load-average=6 --verbose --tree >>> --with-bdeps=y --keep-going" >> >> OK, I got my atom server (which is amd64) to emerge glibc. The trick >> was to reboot it; it had several weeks uptime, I suppose something >> "stale" was in there. I rebooted it, emerged glibc, and everything is >> fine. > > Good to know. I'm still trying to figure out why emerging glibc, > specifically, breaks/broke two out of three systems for me.
I don't know what's left to try. All the libraries warned about below are owned by glibc, and I've re-emerged binutils many times already. Some of the output from gdb: Reading symbols from /bash...(no debugging symbols found)...done. [New LWP 6049] warning: Can't read pathname for load map: Input/output error. warning: .dynamic section for "/lib64/libdl.so.2" is not at the expected address (wrong library or version mismatch?) warning: .dynamic section for "/lib64/libc.so.6" is not at the expected address (wrong library or version mismatch?) warning: .dynamic section for "/lib64/ld-linux-x86-64.so.2" is not at the expected address (wrong library or version mismatch?) warning: .dynamic section for "/lib64/libnss_files.so.2" is not at the expected address (wrong library or version mismatch?) Core was generated by `bash'. Program terminated with signal 11, Segmentation fault. #0 0x00007f9a94dbdc40 in ?? () -- :wq