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

Reply via email to