[gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Michael Mol]

I've had two segfaults I'd never seen before. One in sudo and one in
rdesktop. Updates later when I get things better tracked down.

-- 
:wq

Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Canek Peláez Valdés]

On Wed, Apr 25, 2012 at 10:09 PM, Michael Mol <mikemol@gmail.com> wrote:
> I've had two segfaults I'd never seen before. One in sudo and one in
> rdesktop. Updates later when I get things better tracked down.

I had a gcc segfault in my atom server, with MAKEOPTS=-j5. With
MAKEOPTS=-j1, I got undefined references while linking some modules.
My desktop and my laptop, however, compiled it without problems.

I haven't had the time to check it, but it seems weird.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Michael Mol]

On Wed, Apr 25, 2012 at 11:50 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Wed, Apr 25, 2012 at 10:09 PM, Michael Mol <mikemol@gmail.com> wrote:
>> I've had two segfaults I'd never seen before. One in sudo and one in
>> rdesktop. Updates later when I get things better tracked down.
>
> I had a gcc segfault in my atom server, with MAKEOPTS=-j5. With
> MAKEOPTS=-j1, I got undefined references while linking some modules.
> My desktop and my laptop, however, compiled it without problems.
>
> I haven't had the time to check it, but it seems weird.
>
> Regards.

Right now, normal emerging of anything fails for me. gdb segfaults on
spawn. Bash segfaults on spawn. I can 'sudo busybox sh', though.
Working with the guys in #gentoo-chat, figuring this thing out.

-- 
:wq

Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Michael Mol]

On Wed, Apr 25, 2012 at 11:50 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Wed, Apr 25, 2012 at 10:09 PM, Michael Mol <mikemol@gmail.com> wrote:
>> I've had two segfaults I'd never seen before. One in sudo and one in
>> rdesktop. Updates later when I get things better tracked down.
>
> I had a gcc segfault in my atom server, with MAKEOPTS=-j5. With
> MAKEOPTS=-j1, I got undefined references while linking some modules.
> My desktop and my laptop, however, compiled it without problems.
>
> I haven't had the time to check it, but it seems weird.

Replacing with a binpackage from packages.gentooexperimental.org got
bash working. Now I'm seeing if I can re-emerge gcc, binutils and
glibc.

If that goes through, I'm going to restart the emerge -e; my resume
stack is probably toast.

-- 
:wq

Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Michael Mol]

On Thu, Apr 26, 2012 at 12:37 AM, Michael Mol <mikemol@gmail.com> wrote:
> On Wed, Apr 25, 2012 at 11:50 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>> On Wed, Apr 25, 2012 at 10:09 PM, Michael Mol <mikemol@gmail.com> wrote:
>>> I've had two segfaults I'd never seen before. One in sudo and one in
>>> rdesktop. Updates later when I get things better tracked down.
>>
>> I had a gcc segfault in my atom server, with MAKEOPTS=-j5. With
>> MAKEOPTS=-j1, I got undefined references while linking some modules.
>> My desktop and my laptop, however, compiled it without problems.
>>
>> I haven't had the time to check it, but it seems weird.
>
> Replacing with a binpackage from packages.gentooexperimental.org got
> bash working. Now I'm seeing if I can re-emerge gcc, binutils and
> glibc.
>
> If that goes through, I'm going to restart the emerge -e; my resume
> stack is probably toast.

Ok, yes. This version of glibc, =sys-libs/glibc-2.14.1-r3, is crud. At
least, if you're doing parallel building. Out of my three machines,
the 8-core box got bit by it, the 4-core box got bit by it, but the
2-core laptop sailed past.

I have a hunch that setting MAKEOPTS="-j1" will fix it for me, and I'm
letting that run as I head off to sleep in a few minutes.

-- 
:wq

Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Michael Mol]

On Thu, Apr 26, 2012 at 1:16 AM, Michael Mol <mikemol@gmail.com> wrote:
> On Thu, Apr 26, 2012 at 12:37 AM, Michael Mol <mikemol@gmail.com> wrote:
>> On Wed, Apr 25, 2012 at 11:50 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>> On Wed, Apr 25, 2012 at 10:09 PM, Michael Mol <mikemol@gmail.com> wrote:
>>>> I've had two segfaults I'd never seen before. One in sudo and one in
>>>> rdesktop. Updates later when I get things better tracked down.
>>>
>>> I had a gcc segfault in my atom server, with MAKEOPTS=-j5. With
>>> MAKEOPTS=-j1, I got undefined references while linking some modules.
>>> My desktop and my laptop, however, compiled it without problems.
>>>
>>> I haven't had the time to check it, but it seems weird.
>>
>> Replacing with a binpackage from packages.gentooexperimental.org got
>> bash working. Now I'm seeing if I can re-emerge gcc, binutils and
>> glibc.
>>
>> If that goes through, I'm going to restart the emerge -e; my resume
>> stack is probably toast.
>
> Ok, yes. This version of glibc, =sys-libs/glibc-2.14.1-r3, is crud. At
> least, if you're doing parallel building. Out of my three machines,
> the 8-core box got bit by it, the 4-core box got bit by it, but the
> 2-core laptop sailed past.
>
> I have a hunch that setting MAKEOPTS="-j1" will fix it for me, and I'm
> letting that run as I head off to sleep in a few minutes.

Note, my experiences and instructions are specific to amd64 boxes. I
don't know if other boxes are affected, and the workaround I'm writing
below is not appropriate for anything but amd64.

Incidentally, you'll know if your box got bit if you do a large set of
emerges which include building glibc, and everything after glibc's
'Install' phase fails. Don't trust emerge's output; at this point,
bash is segfaulting on startup, which makes emerge utterly unreliable,
even as it tries to tell you the cause for errors.

DO NOT close your open shells; you won't be able to launch bash until
you've fixed this.

To work around, you'll need a root shell. If you have any shell at
all, you should be able to get a root shell by running

  sudo busybox sh

in any of your remaining shells which have sudoer access.

grab

  glibc-2.14.1-r3.tbz2

from

  http://packages.gentooexperimental.org/packages/amd64-unstable/sys-libs/

using wget. At least in my situation, wget still worked. Move the
tarball to your / directory:

  mv glibc-2.14.1-r3.tbz2 /

and unpack it

  tar xvjpf glibc-2.14.1-r3.tbz2

You should now have bash back, which means you'll have emerge back,
and probably the rest of your system.

-- 
:wq

Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Michael Mol]

On Thu, Apr 26, 2012 at 1:25 AM, Michael Mol <mikemol@gmail.com> wrote:
> On Thu, Apr 26, 2012 at 1:16 AM, Michael Mol <mikemol@gmail.com> wrote:
>> On Thu, Apr 26, 2012 at 12:37 AM, Michael Mol <mikemol@gmail.com> wrote:
>>> On Wed, Apr 25, 2012 at 11:50 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>>> On Wed, Apr 25, 2012 at 10:09 PM, Michael Mol <mikemol@gmail.com> wrote:
>>>>> I've had two segfaults I'd never seen before. One in sudo and one in
>>>>> rdesktop. Updates later when I get things better tracked down.
>>>>
>>>> I had a gcc segfault in my atom server, with MAKEOPTS=-j5. With
>>>> MAKEOPTS=-j1, I got undefined references while linking some modules.
>>>> My desktop and my laptop, however, compiled it without problems.
>>>>
>>>> I haven't had the time to check it, but it seems weird.
>>>
>>> Replacing with a binpackage from packages.gentooexperimental.org got
>>> bash working. Now I'm seeing if I can re-emerge gcc, binutils and
>>> glibc.
>>>
>>> If that goes through, I'm going to restart the emerge -e; my resume
>>> stack is probably toast.
>>
>> Ok, yes. This version of glibc, =sys-libs/glibc-2.14.1-r3, is crud. At
>> least, if you're doing parallel building. Out of my three machines,
>> the 8-core box got bit by it, the 4-core box got bit by it, but the
>> 2-core laptop sailed past.
>>
>> I have a hunch that setting MAKEOPTS="-j1" will fix it for me, and I'm
>> letting that run as I head off to sleep in a few minutes.
>
> Note, my experiences and instructions are specific to amd64 boxes. I
> don't know if other boxes are affected, and the workaround I'm writing
> below is not appropriate for anything but amd64.
>
> Incidentally, you'll know if your box got bit if you do a large set of
> emerges which include building glibc, and everything after glibc's
> 'Install' phase fails. Don't trust emerge's output; at this point,
> bash is segfaulting on startup, which makes emerge utterly unreliable,
> even as it tries to tell you the cause for errors.
>
> DO NOT close your open shells; you won't be able to launch bash until
> you've fixed this.
>
> To work around, you'll need a root shell. If you have any shell at
> all, you should be able to get a root shell by running
>
>  sudo busybox sh
>
> in any of your remaining shells which have sudoer access.
>
> grab
>
>  glibc-2.14.1-r3.tbz2
>
> from
>
>  http://packages.gentooexperimental.org/packages/amd64-unstable/sys-libs/
>
> using wget. At least in my situation, wget still worked. Move the
> tarball to your / directory:
>
>  mv glibc-2.14.1-r3.tbz2 /
>
> and unpack it
>
>  tar xvjpf glibc-2.14.1-r3.tbz2
>
> You should now have bash back, which means you'll have emerge back,
> and probably the rest of your system.

MAKEOPTS="-j1" didn't fix it. Off to find another solution.
-- 
:wq

Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Qian Qiao]

On Thu, Apr 26, 2012 at 19:40, Michael Mol <mikemol@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.

-- Joe

Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Michael Mol]

On Thu, Apr 26, 2012 at 10:34 AM, Qian Qiao <qian.qiao@gmail.com> wrote:
> On Thu, Apr 26, 2012 at 19:40, Michael Mol <mikemol@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

Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Paul Hartman]

On Thu, Apr 26, 2012 at 9:41 AM, Michael Mol <mikemol@gmail.com> wrote:
> 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.

Just to cover all possibilities... since everyone else is saying it's
not a problem for them -- have you run a memory test?

Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Michael Mol]

On Thu, Apr 26, 2012 at 11:01 AM, Paul Hartman
<paul.hartman+gentoo@gmail.com> wrote:
> On Thu, Apr 26, 2012 at 9:41 AM, Michael Mol <mikemol@gmail.com> wrote:
>> 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.
>
> Just to cover all possibilities... since everyone else is saying it's
> not a problem for them -- have you run a memory test?

Not going to be a memory issue.

1) It killed two different boxes at the same time, and one of those
has 10GB of ECC memory.
2) On the machine I can still get into, It consistently breaks each
time I emerge glibc locally, and it consistently works if I unpack the
tarball I noted from gentooexperimental.org.

-- 
:wq

Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Qian Qiao]

On Thu, Apr 26, 2012 at 22:41, Michael Mol <mikemol@gmail.com> wrote:
> On Thu, Apr 26, 2012 at 10:34 AM, Qian Qiao <qian.qiao@gmail.com> wrote:
>> On Thu, Apr 26, 2012 at 19:40, Michael Mol <mikemol@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.

I thought glibc doesn't use distcc even if you have it enabled.
Correct me if I'm wrong though.

Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Mark Knecht]

On Thu, Apr 26, 2012 at 7:41 AM, Michael Mol <mikemol@gmail.com> wrote:
> On Thu, Apr 26, 2012 at 10:34 AM, Qian Qiao <qian.qiao@gmail.com> wrote:
>> On Thu, Apr 26, 2012 at 19:40, Michael Mol <mikemol@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.

- Mark

Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Michael Mol]

On Thu, Apr 26, 2012 at 11:27 AM, Mark Knecht <markknecht@gmail.com> wrote:
> On Thu, Apr 26, 2012 at 7:41 AM, Michael Mol <mikemol@gmail.com> wrote:
>> On Thu, Apr 26, 2012 at 10:34 AM, Qian Qiao <qian.qiao@gmail.com> wrote:
>>> On Thu, Apr 26, 2012 at 19:40, Michael Mol <mikemol@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"



-- 
:wq

Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Canek Peláez Valdés]

On Thu, Apr 26, 2012 at 11:53 AM, Michael Mol <mikemol@gmail.com> wrote:
> On Thu, Apr 26, 2012 at 11:27 AM, Mark Knecht <markknecht@gmail.com> wrote:
>> On Thu, Apr 26, 2012 at 7:41 AM, Michael Mol <mikemol@gmail.com> wrote:
>>> On Thu, Apr 26, 2012 at 10:34 AM, Qian Qiao <qian.qiao@gmail.com> wrote:
>>>> On Thu, Apr 26, 2012 at 19:40, Michael Mol <mikemol@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.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Michael Mol]

On Thu, Apr 26, 2012 at 2:20 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Thu, Apr 26, 2012 at 11:53 AM, Michael Mol <mikemol@gmail.com> wrote:
>> On Thu, Apr 26, 2012 at 11:27 AM, Mark Knecht <markknecht@gmail.com> wrote:
>>> On Thu, Apr 26, 2012 at 7:41 AM, Michael Mol <mikemol@gmail.com> wrote:
>>>> On Thu, Apr 26, 2012 at 10:34 AM, Qian Qiao <qian.qiao@gmail.com> wrote:
>>>>> On Thu, Apr 26, 2012 at 19:40, Michael Mol <mikemol@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.


-- 
:wq

Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Michael Mol]

On Thu, Apr 26, 2012 at 2:26 PM, Michael Mol <mikemol@gmail.com> wrote:
> On Thu, Apr 26, 2012 at 2:20 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>> On Thu, Apr 26, 2012 at 11:53 AM, Michael Mol <mikemol@gmail.com> wrote:
>>> On Thu, Apr 26, 2012 at 11:27 AM, Mark Knecht <markknecht@gmail.com> wrote:
>>>> On Thu, Apr 26, 2012 at 7:41 AM, Michael Mol <mikemol@gmail.com> wrote:
>>>>> On Thu, Apr 26, 2012 at 10:34 AM, Qian Qiao <qian.qiao@gmail.com> wrote:
>>>>>> On Thu, Apr 26, 2012 at 19:40, Michael Mol <mikemol@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

Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Volker Armin Hemmann]

Am Donnerstag, 26. April 2012, 12:53:28 schrieb Michael Mol:
> On Thu, Apr 26, 2012 at 11:27 AM, Mark Knecht <markknecht@gmail.com> wrote:
> > On Thu, Apr 26, 2012 at 7:41 AM, Michael Mol <mikemol@gmail.com> wrote:
> >> On Thu, Apr 26, 2012 at 10:34 AM, Qian Qiao <qian.qiao@gmail.com> wrote:
> >>> On Thu, Apr 26, 2012 at 19:40, Michael Mol <mikemol@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"

and now try without ggdb3 and splitdebug.

-- 
#163933

Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Adam Carter]

> #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"

FYI Michael, i'm not too dissimilar, and no apparent problems with
glibc-2.14.1-r3. Mostly stable, kernel from gentoo-sources 3.3.2.

CFLAGS="-march=amdfam10 -mcx16 -msahf -mpopcnt -mabm -O2 -pipe"
CXXFLAGS="${CFLAGS}"
CHOST="x86_64-pc-linux-gnu"
#MAKEOPTS="-j1"
MAKEOPTS="-j4"
#FEATURES="ccache parallel-fetch buildsyspkg distcc"
FEATURES="-sandbox ccache parallel-fetch buildsyspkg"
LINGUAS="en"
EMERGE_DEFAULT_OPTS="--keep-going --autounmask y"

Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Michael Mol]

On Thu, Apr 26, 2012 at 8:35 PM, Adam Carter <adamcarter3@gmail.com> wrote:
>> #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"
>
> FYI Michael, i'm not too dissimilar, and no apparent problems with
> glibc-2.14.1-r3. Mostly stable, kernel from gentoo-sources 3.3.2.

Running 3.2.12-gentoo on all systems here.

>
> CFLAGS="-march=amdfam10 -mcx16 -msahf -mpopcnt -mabm -O2 -pipe"
> CXXFLAGS="${CFLAGS}"
> CHOST="x86_64-pc-linux-gnu"
> #MAKEOPTS="-j1"
> MAKEOPTS="-j4"
> #FEATURES="ccache parallel-fetch buildsyspkg distcc"
> FEATURES="-sandbox ccache parallel-fetch buildsyspkg"
> LINGUAS="en"
> EMERGE_DEFAULT_OPTS="--keep-going --autounmask y"
>

Yeah, that's pretty similar to mine.

Lost my SSH session to inara (inara and kaylee are the two systems
that are borked by the upgrade, saffron is the one system I have which
upgraded without problem) when saffron hung coming out of screensaver.
I can no longer ssh into either inara or kaylee. And I won't have time
to work with either until Sunday at the earliest.

This has not been a good week.

-- 
:wq

RE: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Mike Edenfield]

 From: Michael Mol [mailto:mikemol@gmail.com]
 Sent: Thursday, April 26, 2012 9:54 PM

>  I can no longer ssh into either inara or kaylee. 

Clearly they are busy fsck'ing /malcom and /simon

Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 1722 bytes --]

On Apr 27, 2012 8:58 AM, "Michael Mol" <mikemol@gmail.com> wrote:
>
> On Thu, Apr 26, 2012 at 8:35 PM, Adam Carter <adamcarter3@gmail.com>
wrote:
> >> #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"
> >
> > FYI Michael, i'm not too dissimilar, and no apparent problems with
> > glibc-2.14.1-r3. Mostly stable, kernel from gentoo-sources 3.3.2.
>
> Running 3.2.12-gentoo on all systems here.
>
> >
> > CFLAGS="-march=amdfam10 -mcx16 -msahf -mpopcnt -mabm -O2 -pipe"
> > CXXFLAGS="${CFLAGS}"
> > CHOST="x86_64-pc-linux-gnu"
> > #MAKEOPTS="-j1"
> > MAKEOPTS="-j4"
> > #FEATURES="ccache parallel-fetch buildsyspkg distcc"
> > FEATURES="-sandbox ccache parallel-fetch buildsyspkg"
> > LINGUAS="en"
> > EMERGE_DEFAULT_OPTS="--keep-going --autounmask y"
> >
>
> Yeah, that's pretty similar to mine.
>
> Lost my SSH session to inara (inara and kaylee are the two systems
> that are borked by the upgrade, saffron is the one system I have which
> upgraded without problem) when saffron hung coming out of screensaver.
> I can no longer ssh into either inara or kaylee. And I won't have time
> to work with either until Sunday at the earliest.
>
> This has not been a good week.
>

How big is your swapfile?

Rgds,

[-- Attachment #2: Type: text/html, Size: 2414 bytes --]

Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 1985 bytes --]

I don't think I have one on kaylee. If I have one on inara, it'd be >=
system RAM, so at least 4G.
On Apr 28, 2012 3:14 AM, "Pandu Poluan" <pandu@poluan.info> wrote:

>
> On Apr 27, 2012 8:58 AM, "Michael Mol" <mikemol@gmail.com> wrote:
> >
> > On Thu, Apr 26, 2012 at 8:35 PM, Adam Carter <adamcarter3@gmail.com>
> wrote:
> > >> #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"
> > >
> > > FYI Michael, i'm not too dissimilar, and no apparent problems with
> > > glibc-2.14.1-r3. Mostly stable, kernel from gentoo-sources 3.3.2.
> >
> > Running 3.2.12-gentoo on all systems here.
> >
> > >
> > > CFLAGS="-march=amdfam10 -mcx16 -msahf -mpopcnt -mabm -O2 -pipe"
> > > CXXFLAGS="${CFLAGS}"
> > > CHOST="x86_64-pc-linux-gnu"
> > > #MAKEOPTS="-j1"
> > > MAKEOPTS="-j4"
> > > #FEATURES="ccache parallel-fetch buildsyspkg distcc"
> > > FEATURES="-sandbox ccache parallel-fetch buildsyspkg"
> > > LINGUAS="en"
> > > EMERGE_DEFAULT_OPTS="--keep-going --autounmask y"
> > >
> >
> > Yeah, that's pretty similar to mine.
> >
> > Lost my SSH session to inara (inara and kaylee are the two systems
> > that are borked by the upgrade, saffron is the one system I have which
> > upgraded without problem) when saffron hung coming out of screensaver.
> > I can no longer ssh into either inara or kaylee. And I won't have time
> > to work with either until Sunday at the earliest.
> >
> > This has not been a good week.
> >
>
> How big is your swapfile?
>
> Rgds,
>

[-- Attachment #2: Type: text/html, Size: 2904 bytes --]

Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 642 bytes --]

On Apr 28, 2012 3:32 PM, "Michael Mol" <mikemol@gmail.com> wrote:
>
> On Apr 28, 2012 3:14 AM, "Pandu Poluan" <pandu@poluan.info> wrote:
>>

---- >8 snip

>>
>> How big is your swapfile?
>>
>> Rgds,
>
> I don't think I have one on kaylee. If I have one on inara, it'd be >=
system RAM, so at least 4G.

Are you sure?

I remember having a lot of grief trying to graphite-ize glibc without a
swapfile. Now, every time I see glibc in the list of "things to emerge", I
swapon /.swapfile (and swapoff that file after emerge us complete).

If you're using distcc, perhaps you need to turn on swapfile temporarily on
all participating hosts.

Rgds,

[-- Attachment #2: Type: text/html, Size: 909 bytes --]

Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 971 bytes --]

Kaylee has 10GB of RAM...if that's not enough, I'll be disabling graphite.
(Though I haven't explicitly enabled it, either.)

But, no I'm not sure, and can't check until Sunday eveningish. Currently at
Penguicon.
On Apr 28, 2012 5:32 AM, "Pandu Poluan" <pandu@poluan.info> wrote:

>
> On Apr 28, 2012 3:32 PM, "Michael Mol" <mikemol@gmail.com> wrote:
> >
> > On Apr 28, 2012 3:14 AM, "Pandu Poluan" <pandu@poluan.info> wrote:
> >>
>
> ---- >8 snip
>
> >>
> >> How big is your swapfile?
> >>
> >> Rgds,
> >
> > I don't think I have one on kaylee. If I have one on inara, it'd be >=
> system RAM, so at least 4G.
>
> Are you sure?
>
> I remember having a lot of grief trying to graphite-ize glibc without a
> swapfile. Now, every time I see glibc in the list of "things to emerge", I
> swapon /.swapfile (and swapoff that file after emerge us complete).
>
> If you're using distcc, perhaps you need to turn on swapfile temporarily
> on all participating hosts.
>
> Rgds,
>

[-- Attachment #2: Type: text/html, Size: 1503 bytes --]

Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Michael Mol]

On Sat, Apr 28, 2012 at 11:07 AM, Michael Mol <mikemol@gmail.com> wrote:
> Kaylee has 10GB of RAM...if that's not enough, I'll be disabling graphite.
> (Though I haven't explicitly enabled it, either.)
>
> But, no I'm not sure, and can't check until Sunday eveningish. Currently at
> Penguicon.

Wow. Just wow. This is incredible.

This is repeatable for me.

My steps:

Start with the 12.1 LiveDVD ( http://www.gentoo.org/news/20120401-livedvd.xml )

Install latest stage 3, latest portage. Set various stuff. USE flags,
make.conf stuff, etc. Get kernel installed, reboot into system, sshd
up, etc.

Now, I essentially reused my existing make.conf file, which is at the
end of this email. I finally get to:

emerge --update --deep --newuse @world

...and once it goes to install glibc, I get:

* The ebuild phase 'postrm' has been killed by signal 11.
 * The 'postrm' phase of the 'sys-libs/glibc-2.14.1-r3' package has failed
 * with exit value 1.
 *
 * The problem occurred while executing the ebuild file named
 * 'glibc-2.14.1-r3.ebuild' located in the '/var/db/pkg/sys-
 * libs/glibc-2.14.1-r3' directory. If necessary, manually remove the
 * environment.bz2 file and/or the ebuild file located in that directory.
 *
 * Removal of the environment.bz2 file is preferred since it may allow the
 * removal phases to execute successfully. The ebuild will be sourced and
 * the eclasses from the current portage tree will be used when necessary.
 * Removal of the ebuild file will cause the pkg_prerm() and pkg_postrm()
 * removal phases to be skipped entirely.

So, once the updated glibc goes in, anything that dynamically links
against it fails on spawn, hence the failure at postinst. This is
crazy.

Make.conf:

CFLAGS="-O2 -pipe -D_FORTIFY_SOURCE=2 -march=core2 -mcx16 -msahf
--param l1-cache-size=32 --param l1-cache-line-size=64 --param
l2-cache-size=4096 -mtune=core2 -ggdb3"
CXXFLAGS="${CFLAGS}"

MAKEOPTS="--jobs --load 8"
EMERGE_DEFAULT_OPTS="--jobs --load-average=8 --verbose --tree
--with-bdeps=y --keep-going"
FEATURES="splitdebug"
LINGUAS="en"
SYS_USE_CPU="mmx sse sse2 sse3 ssse3 openmp opencl cuda posix nptl
multilib smp lapack"
SYS_USE_LANG="perl python tcl"
SYS_USE_TOOLKITS="gtk"
SYS_USE_GAPI="gd sdl ncurses xcb opengl v4l vdpau xv X dri"
SYS_USE_AAPI="openal alsa"
SYS_USE_OTHER="acl alsa cdr crypt cups dvd dvdr firefox gmp iconv
nsplugin offensive pcre pda rss spell taglib truetype videos
vim-syntax xattr xcomposite xft xinerama xml xscreensaver fontconfig
qt3support phonon"
SYS_USE_COMPRESSION="bzip2 gzip lzma lzo szip zlib"
SYS_USE_MEDIA_GFX="imagemagick jpeg jpeg2k openexr png raw svg tiff wmf mng"
SYS_USE_MEDIA_AUDIO="aac cdda flac gsm lame mad mikmod shorten speex
timidity vorbis mp3 midi"
SYS_USE_MEDIA_VIDEO="css dv ffmpeg theora x264 xvid"
SYS_USE_MEDIA_CONTAINERS="matroska mms mp4 mpeg ogg pdf quicktime vcd"
SYS_USE_MEDIA="${SYS_USE_MEDIA_GFX} ${SYS_USE_MEDIA_AUDIO}
${SYS_USE_MEDIA_VIDEO} ${SYS_USE_MEDIA_CONTAINERS} sound cddb encode
exif gimp libsamplerate mtp ppds sndfile sox wavpack xmp latex"
SYS_USE_NET="avahi curl ftp geoip gnutls ipv6 libwww rdesktop samba
sockets ssl tcpd vnc"
SYS_USE_PLATFORM="acpi dbus fam hddtemp ieee1394 joystick libnotify
lm_sensors pam readline sharedmem syslog sysvipc threads udev unicode
usb"
SYS_USE_DONOTWANT="-pulseaudio -gnome -oss -berkdb -gdbm"
USE="${SYS_USE_CPU} ${SYS_USE_LANG} ${SYS_USE_TOOLKITS}
${SYS_USE_GAPI} ${SYS_USE_AAPI} ${SYS_USE_OTHER} ${SYS_USE_MEDIA}
${SYS_USE_COMPRESSION} ${SYS_USE_NET} ${SYS_USE_PLATFORM}
${SYS_USE_DONOTWANT}"
GENTOO_MIRRORS="http://chi-10g-1-mirror.fastsoft.net/pub/linux/gentoo/gentoo-distfiles/
http://mirrors.cs.wmich.edu/gentoo
http://gentoo.mirrors.tds.net/gentoo"
SYNC="rsync://rsync29.us.gentoo.org/gentoo-portage"

VIDEO_CARDS="nvidia"
INPUT_DEVICES="evdev"
ALSA_CARDS=""

ACCEPT_LICENSE="AdobeFlash-10.3"
PORTAGE_BINHOST="http://binhost.ossdl.de/x86_64-pc-linux-gnu/"

#PKGDIR="/mnt/r5/pkgdir"
#PORTAGE_TMPDIR="/mnt/r5/portage_tmp"

CHOST="x86_64-pc-linux-gnu"

-- 
:wq

Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Dmitry Goncharov]

On Sat, Jun 02, 2012 at 10:52:12PM -0400, Michael Mol wrote:
> On Sat, Apr 28, 2012 at 11:07 AM, Michael Mol <mikemol@gmail.com> wrote:
> Wow. Just wow. This is incredible.
> 
> This is repeatable for me.
> 
<snip>
>  * The problem occurred while executing the ebuild file named
>  * 'glibc-2.14.1-r3.ebuild' located in the '/var/db/pkg/sys-
> 
<snip>
> CFLAGS="-O2 -pipe -D_FORTIFY_SOURCE=2 -march=core2 -mcx16 -msahf
> --param l1-cache-size=32 --param l1-cache-line-size=64 --param
> l2-cache-size=4096 -mtune=core2 -ggdb3"
> CXXFLAGS="${CFLAGS}"

Can you upgrage to glibc-2.15?
Can you tweak you gcc flags to something more conventional and see if the
problem persists?
If you are interested in submitting a patch to the upstream then you can build
the glibc test suite with your gcc flags and check if the tests pass.

regards, Dmitry

Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Michael Mol]

On Sat, Jun 2, 2012 at 11:34 PM, Dmitry Goncharov
<dgoncharov@users.sf.net> wrote:
> On Sat, Jun 02, 2012 at 10:52:12PM -0400, Michael Mol wrote:
>> On Sat, Apr 28, 2012 at 11:07 AM, Michael Mol <mikemol@gmail.com> wrote:
>> Wow. Just wow. This is incredible.
>>
>> This is repeatable for me.
>>
> <snip>
>>  * The problem occurred while executing the ebuild file named
>>  * 'glibc-2.14.1-r3.ebuild' located in the '/var/db/pkg/sys-
>>
> <snip>
>> CFLAGS="-O2 -pipe -D_FORTIFY_SOURCE=2 -march=core2 -mcx16 -msahf
>> --param l1-cache-size=32 --param l1-cache-line-size=64 --param
>> l2-cache-size=4096 -mtune=core2 -ggdb3"
>> CXXFLAGS="${CFLAGS}"
>
> Can you upgrage to glibc-2.15?

Sure. It's going to be another full reinstall.

> Can you tweak you gcc flags to something more conventional and see if the
> problem persists?

Those CFLAGS should be equivalent to:
CFLAGS="-O2 -pipe -ggdb3 --march=native".

But I'll try making it just -O2 -pipe --march=native.

> If you are interested in submitting a patch to the upstream then you can build
> the glibc test suite with your gcc flags and check if the tests pass.

If it gets things fixed. I have two machines which have been offline
for almost two months from this.

-- 
:wq

Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Dmitry Goncharov]

On Sat, Jun 02, 2012 at 11:56:01PM -0400, Michael Mol wrote:
> On Sat, Jun 2, 2012 at 11:34 PM, Dmitry Goncharov
> <dgoncharov@users.sf.net> wrote:
> > On Sat, Jun 02, 2012 at 10:52:12PM -0400, Michael Mol wrote:
> >> On Sat, Apr 28, 2012 at 11:07 AM, Michael Mol <mikemol@gmail.com> wrote:
> >> Wow. Just wow. This is incredible.
> >>
> >> This is repeatable for me.
> >>
> > <snip>
> >>  * The problem occurred while executing the ebuild file named
> >>  * 'glibc-2.14.1-r3.ebuild' located in the '/var/db/pkg/sys-
> >>
> > <snip>
> >> CFLAGS="-O2 -pipe -D_FORTIFY_SOURCE=2 -march=core2 -mcx16 -msahf
> >> --param l1-cache-size=32 --param l1-cache-line-size=64 --param
> >> l2-cache-size=4096 -mtune=core2 -ggdb3"
> >> CXXFLAGS="${CFLAGS}"
> >
> > Can you upgrage to glibc-2.15?
> 
> Sure. It's going to be another full reinstall.
> 
> > Can you tweak you gcc flags to something more conventional and see if the
> > problem persists?
> 
> Those CFLAGS should be equivalent to:
> CFLAGS="-O2 -pipe -ggdb3 --march=native".
> 
> But I'll try making it just -O2 -pipe --march=native.
> 
> > If you are interested in submitting a patch to the upstream then you can build
> > the glibc test suite with your gcc flags and check if the tests pass.
> 
> If it gets things fixed. I have two machines which have been offline
> for almost two months from this.
> 
> -- 
> :wq
> 
Also, which gcc are you using? Can you try a different version?

regards, Dmitry

Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Michael Mol]

On Sun, Jun 3, 2012 at 12:08 AM, Dmitry Goncharov
<dgoncharov@users.sf.net> wrote:
> On Sat, Jun 02, 2012 at 11:56:01PM -0400, Michael Mol wrote:
>> On Sat, Jun 2, 2012 at 11:34 PM, Dmitry Goncharov
>> <dgoncharov@users.sf.net> wrote:
>> > On Sat, Jun 02, 2012 at 10:52:12PM -0400, Michael Mol wrote:
>> >> On Sat, Apr 28, 2012 at 11:07 AM, Michael Mol <mikemol@gmail.com> wrote:
>> >> Wow. Just wow. This is incredible.
>> >>
>> >> This is repeatable for me.
>> >>
>> > <snip>
>> >>  * The problem occurred while executing the ebuild file named
>> >>  * 'glibc-2.14.1-r3.ebuild' located in the '/var/db/pkg/sys-
>> >>
>> > <snip>
>> >> CFLAGS="-O2 -pipe -D_FORTIFY_SOURCE=2 -march=core2 -mcx16 -msahf
>> >> --param l1-cache-size=32 --param l1-cache-line-size=64 --param
>> >> l2-cache-size=4096 -mtune=core2 -ggdb3"
>> >> CXXFLAGS="${CFLAGS}"
>> >
>> > Can you upgrage to glibc-2.15?
>>
>> Sure. It's going to be another full reinstall.
>>
>> > Can you tweak you gcc flags to something more conventional and see if the
>> > problem persists?
>>
>> Those CFLAGS should be equivalent to:
>> CFLAGS="-O2 -pipe -ggdb3 --march=native".
>>
>> But I'll try making it just -O2 -pipe --march=native.
>>
>> > If you are interested in submitting a patch to the upstream then you can build
>> > the glibc test suite with your gcc flags and check if the tests pass.
>>
>> If it gets things fixed. I have two machines which have been offline
>> for almost two months from this.
>>
>> --
>> :wq
>>
> Also, which gcc are you using? Can you try a different version?

It updated gcc immediately before glibc, IIRC, so I expect it's newest
stable. Kaylee is offline until I do a new reinstall again, but it
looks like latest stable in portage is 4.5.3-r2.

-- 
:wq

Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Michael Mol]

On Sat, Jun 2, 2012 at 11:56 PM, Michael Mol <mikemol@gmail.com> wrote:
> On Sat, Jun 2, 2012 at 11:34 PM, Dmitry Goncharov
> <dgoncharov@users.sf.net> wrote:
>> On Sat, Jun 02, 2012 at 10:52:12PM -0400, Michael Mol wrote:
>>> On Sat, Apr 28, 2012 at 11:07 AM, Michael Mol <mikemol@gmail.com> wrote:
>>> Wow. Just wow. This is incredible.
>>>
>>> This is repeatable for me.
>>>
>> <snip>
>>>  * The problem occurred while executing the ebuild file named
>>>  * 'glibc-2.14.1-r3.ebuild' located in the '/var/db/pkg/sys-
>>>
>> <snip>
>>> CFLAGS="-O2 -pipe -D_FORTIFY_SOURCE=2 -march=core2 -mcx16 -msahf
>>> --param l1-cache-size=32 --param l1-cache-line-size=64 --param
>>> l2-cache-size=4096 -mtune=core2 -ggdb3"
>>> CXXFLAGS="${CFLAGS}"
>>
>> Can you upgrage to glibc-2.15?
>
> Sure. It's going to be another full reinstall.

Forgot to try this. Will do tomorrow.

>
>> Can you tweak you gcc flags to something more conventional and see if the
>> problem persists?
>
> Those CFLAGS should be equivalent to:
> CFLAGS="-O2 -pipe -ggdb3 --march=native".
>
> But I'll try making it just -O2 -pipe --march=native.

Just an update: Tried CFLAGS="-O2 -pipe --march=native -ggdb3". Same results.

>
>> If you are interested in submitting a patch to the upstream then you can build
>> the glibc test suite with your gcc flags and check if the tests pass.

I do still have a working gentoo laptop I could try this on...but it
has an i3 proc, as opposed to the core 2 xeon or the phenom 9650. Have
a link to instructions?

-- 
:wq

Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Michael Mol]

On Sat, Jun 23, 2012 at 12:37 AM, Michael Mol <mikemol@gmail.com> wrote:
> On Sat, Jun 2, 2012 at 11:56 PM, Michael Mol <mikemol@gmail.com> wrote:
>> On Sat, Jun 2, 2012 at 11:34 PM, Dmitry Goncharov
>> <dgoncharov@users.sf.net> wrote:
>>> On Sat, Jun 02, 2012 at 10:52:12PM -0400, Michael Mol wrote:
>>>> On Sat, Apr 28, 2012 at 11:07 AM, Michael Mol <mikemol@gmail.com> wrote:
>>>> Wow. Just wow. This is incredible.
>>>>
>>>> This is repeatable for me.
>>>>
>>> <snip>
>>>>  * The problem occurred while executing the ebuild file named
>>>>  * 'glibc-2.14.1-r3.ebuild' located in the '/var/db/pkg/sys-
>>>>
>>> <snip>
>>>> CFLAGS="-O2 -pipe -D_FORTIFY_SOURCE=2 -march=core2 -mcx16 -msahf
>>>> --param l1-cache-size=32 --param l1-cache-line-size=64 --param
>>>> l2-cache-size=4096 -mtune=core2 -ggdb3"
>>>> CXXFLAGS="${CFLAGS}"
>>>
>>> Can you upgrage to glibc-2.15?
>>
>> Sure. It's going to be another full reinstall.
>
> Forgot to try this. Will do tomorrow.
>
>>
>>> Can you tweak you gcc flags to something more conventional and see if the
>>> problem persists?
>>
>> Those CFLAGS should be equivalent to:
>> CFLAGS="-O2 -pipe -ggdb3 --march=native".
>>
>> But I'll try making it just -O2 -pipe --march=native.
>
> Just an update: Tried CFLAGS="-O2 -pipe --march=native -ggdb3". Same results.
>
>>
>>> If you are interested in submitting a patch to the upstream then you can build
>>> the glibc test suite with your gcc flags and check if the tests pass.
>
> I do still have a working gentoo laptop I could try this on...but it
> has an i3 proc, as opposed to the core 2 xeon or the phenom 9650. Have
> a link to instructions?

For anyone following or interested, this is now reported as bug
#423149. I'll be tracking progress there, so I have a common place to
keep notes and discoveries as I try to work it out.

https://bugs.gentoo.org/show_bug.cgi?id=423149

-- 
:wq

[SOLVED] Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Michael Mol]

On Sat, Jun 23, 2012 at 6:08 PM, Michael Mol <mikemol@gmail.com> wrote:
> https://bugs.gentoo.org/show_bug.cgi?id=423149

As it turned out, it was my CFLAGS. Not the ones anyone usually cares
about, either.

If you build glibc with CFLAGS="${CFLAGS} -g3", your glibc will be
very, very broken. Apparently, it's old, known and has been a problem
for about five years.[1]

Which means that when I changed my CFLAGS from "-ggdb" to "-ggdb3" a
few months ago, the next time I emerged glibc was going to be the time
that killed my system. I didn't think twice about it at the time,
either; When trying to debug something, how often does it turn out to
be the debugging *data* that's causing the problem? I'm accustomed to
systems behaving differently with debuggers attached, but this
was...bizarre.

The other big thing I kept hearing about was "try changing
{this|that|other thing}; it might be affecting glibc, because glibc is
a whiny b*tch". Are there alternatives to glibc?

Meanwhile, while trying to accelerate the tweak/retry cycle of testing
this, I wrote a script which automatically installs, configures,
updates and builds Gentoo. I'll share it on github soon enough; it's
got a bunch of pieces which are particular to my use case. Just a
couple more changes before it generates a clean, configured system
(for me). Once I've got a stable, working box at home, I'll be able to
refine it.

[1] http://twitter.com/flameeyes/status/217361466158874626

-- 
:wq

Re: [SOLVED] Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Hinnerk van Bruinehsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 27.06.2012 15:58, Michael Mol wrote:
<SNIP>
> 
> The other big thing I kept hearing about was "try changing 
> {this|that|other thing}; it might be affecting glibc, because glibc
> is a whiny b*tch". Are there alternatives to glibc?
> 
<SNIP>

Alternatives? Hardly, I think. There are some "lightweight" variants:

- - sys-libs/uclibc
http://www.uclibc.org/

- - dev-libs/dietlibc
http://www.fefe.de/dietlibc/

comes to mind, but afaik they don't have the full functionality of
glibc. uclibc seems to be enough for XFCE, though (there is a hardened
stage4 with XFCE named lilblue made by blueness)

WKR
Hinnerk

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJP6xooAAoJEJwwOFaNFkYc0awH/0409HsXvLNgHV4PIE6Jn3Ar
vDOP0yxlmnSwCBcaOlmZoXn3nOiY3AlL5EQtqFM2RJdBv1YMPLtyboqLqbff/Im4
U2Akr7qxXu0qZogwnBYKSHDsupqcTUB4PNS6J0HDvCzeBlaZFF5bgw6P1eD6nRct
A4R2wtIwKEoCbUxzSZxjSG0IGTcPruMlX2yV67Yukvsl+XhjoQxhkO3DPECoivpx
0Oqu8dP7mIgVe0Sh9nApZTMgsrw3hH5ezDo9reNKROgCDIjegKvqI5Ts8P1XzjZn
68UTN0pelaj3j7wciM9aUYxu48p4J5pTQfE3t4/T5/DVsBlHqHfqR4kBqSG7Dhw=
=PPAJ
-----END PGP SIGNATURE-----

Re: [SOLVED] Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 510 bytes --]

On Wed, 27 Jun 2012 09:58:57 -0400, Michael Mol wrote:

> If you build glibc with CFLAGS="${CFLAGS} -g3", your glibc will be
> very, very broken. Apparently, it's old, known and has been a problem
> for about five years.[1]

Thisd sounds worthy of a bug report, an ebuild allowing you to break
something as critical as glibc without even a warning does not sound good.


-- 
Neil Bothwick

Ralph's Observation - It is a mistake to allow any mechanical object
to realize that you are in a hurry.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [SOLVED] Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Michael Mol]

On Wed, Jun 27, 2012 at 12:12 PM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Wed, 27 Jun 2012 09:58:57 -0400, Michael Mol wrote:
>
>> If you build glibc with CFLAGS="${CFLAGS} -g3", your glibc will be
>> very, very broken. Apparently, it's old, known and has been a problem
>> for about five years.[1]
>
> Thisd sounds worthy of a bug report, an ebuild allowing you to break
> something as critical as glibc without even a warning does not sound good.

Take a look at my bugreport: https://bugs.gentoo.org/show_bug.cgi?id=423149

And then follow through to the bug report it was marked as a duplicate
of. Gentoo devs, at least, know of the problem, but don't want to put
a workaround in the ebuild for it.

Also, even if the ebuild issued a warning, there's no guarantee the
warning would ever be made visible; the system is well and truly hosed
before the 'postinst' stage of the install, so who knows whether or
not the cache-and-show-later warnings would reach the user?

-- 
:wq

Re: [SOLVED] Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 568 bytes --]

On Wed, 27 Jun 2012 12:45:13 -0400, Michael Mol wrote:

> Also, even if the ebuild issued a warning, there's no guarantee the
> warning would ever be made visible; the system is well and truly hosed
> before the 'postinst' stage of the install, so who knows whether or
> not the cache-and-show-later warnings would reach the user?

There is a facility for an ebuild to check things like this and override
them or refuse to continue, unless you set $I_KNOW_WHAT_I_AM_DOING.


-- 
Neil Bothwick

In plumbing, a straight flush is better than a full house.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [SOLVED] Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Michael Mol]

On Wed, Jun 27, 2012 at 1:05 PM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Wed, 27 Jun 2012 12:45:13 -0400, Michael Mol wrote:
>
>> Also, even if the ebuild issued a warning, there's no guarantee the
>> warning would ever be made visible; the system is well and truly hosed
>> before the 'postinst' stage of the install, so who knows whether or
>> not the cache-and-show-later warnings would reach the user?
>
> There is a facility for an ebuild to check things like this and override
> them or refuse to continue, unless you set $I_KNOW_WHAT_I_AM_DOING.

I'll file an enhancement request against the ebuild tonight. (I hope,
if I find time.)


-- 
:wq

Re: [SOLVED] Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Paul Hartman]

On Wed, Jun 27, 2012 at 8:58 AM, Michael Mol <mikemol@gmail.com> wrote:
> On Sat, Jun 23, 2012 at 6:08 PM, Michael Mol <mikemol@gmail.com> wrote:
>> https://bugs.gentoo.org/show_bug.cgi?id=423149
>
> As it turned out, it was my CFLAGS. Not the ones anyone usually cares
> about, either.
>
> If you build glibc with CFLAGS="${CFLAGS} -g3", your glibc will be
> very, very broken. Apparently, it's old, known and has been a problem
> for about five years.

Thanks for posting this follow-up, I never would have guessed the
additional debug info could cause such problems.

Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Andrea Conti]

> Ok, yes. This version of glibc, =sys-libs/glibc-2.14.1-r3, is crud.

It's the current stable version on amd64, and you seem to be the only
one having problems with it.

I think the problem is likely with your setup (i.e. other toolchain
component, CFLAGS, ...).

> least, if you're doing parallel building. Out of my three machines,
> the 8-core box got bit by it, the 4-core box got bit by it, but the
> 2-core laptop sailed past.

Been running 2.14.1-r3 on an amd64 16-core server for a couple of weeks.
MAKEOPTS is at -j20.

No crashes so far, emerge keeps working and the machine had no problems
rebooting after a kernel update.

andrea

Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Volker Armin Hemmann]

Am Mittwoch, 25. April 2012, 22:50:53 schrieb Canek Peláez Valdés:
> On Wed, Apr 25, 2012 at 10:09 PM, Michael Mol <mikemol@gmail.com> wrote:
> > I've had two segfaults I'd never seen before. One in sudo and one in
> > rdesktop. Updates later when I get things better tracked down.
> 
> I had a gcc segfault in my atom server, with MAKEOPTS=-j5. With
> MAKEOPTS=-j1, I got undefined references while linking some modules.
> My desktop and my laptop, however, compiled it without problems.
> 
> I haven't had the time to check it, but it seems weird.
> 
> Regards.


sys-libs/glibc
     Available versions:  (2.2) (~)2.9_p20081201-r3!s 2.10.1-r1!s 2.11.3!s 
(~)2.12.1-r3!s 2.12.2!s (~)2.13-r2!s 2.13-r4!s (~)2.14!s (~)2.14.1-r2!s 
2.14.1-r3!s{tbz2} (~)2.15-r1!s **9999!s
        {{crosscompile_opts_headers-only debug gd hardened multilib profile 
selinux vanilla}}
     Installed versions:  2.14.1-r3(2.2)!s{tbz2}(18:59:22 14.04.2012)(gd 
glibc-omitfp multilib -crosscompile_opts_headers-only -debug -hardened -profile 
-selinux -vanilla)
     Homepage:            http://www.gnu.org/software/libc/libc.html
     Description:         GNU libc6 (also called glibc2) C library


and everything being fine here.

-- 
#163933

[gentoo-user] Re: Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Nikos Chantziaras]

On 26/04/12 06:09, Michael Mol wrote:
> I've had two segfaults I'd never seen before. One in sudo and one in
> rdesktop. Updates later when I get things better tracked down.

Hmm.  Been running 2.14.1-r2 since January, and 2.14.1-r3 since April 
14.  No problems (~amd64).

Re: [gentoo-user] Re: Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Dale]

Nikos Chantziaras wrote:
> On 26/04/12 06:09, Michael Mol wrote:
>> I've had two segfaults I'd never seen before. One in sudo and one in
>> rdesktop. Updates later when I get things better tracked down.
> 
> Hmm.  Been running 2.14.1-r2 since January, and 2.14.1-r3 since April
> 14.  No problems (~amd64).
> 
> 
> 


About the same here.  I'm amd64 and 4 cores running with -j10 or
something.  I have not ran a emerge -e world tho.  Sort of scared to try
it now.  :/

Wonder why some are affected and some are not?

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

Re: [gentoo-user] Re: Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[napalm]

[-- Attachment #1: Type: text/plain, Size: 498 bytes --]

On Thu, Apr 26, 2012 at 10:01:51AM +0300, Nikos Chantziaras wrote:
> On 26/04/12 06:09, Michael Mol wrote:
> > I've had two segfaults I'd never seen before. One in sudo and one in
> > rdesktop. Updates later when I get things better tracked down.
> 
> Hmm.  Been running 2.14.1-r2 since January, and 2.14.1-r3 since April 
> 14.  No problems (~amd64).
> 
Yeah as have I, I've even rebuilt @world since installing
glibc-2.14.1-r3 on the hardened porfile on amd64 with no problems at
all.

[-- Attachment #2: Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Helmut Jarausch]

On 04/26/2012 05:09:58 AM, Michael Mol wrote:
> I've had two segfaults I'd never seen before. One in sudo and one in
> rdesktop. Updates later when I get things better tracked down.

I am at glibc-2.15-r1 on AMD64 with no problems so far,

Helmut.

Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Doug Hunley]

On Thu, Apr 26, 2012 at 04:47, Helmut Jarausch
<jarausch@igpm.rwth-aachen.de> wrote:
> I am at glibc-2.15-r1 on AMD64 with no problems so far,

ditto here

-- 
Douglas J Hunley (doug.hunley@gmail.com)
Twitter: @hunleyd                                               Web:
douglasjhunley.com
G+: http://goo.gl/sajR3

Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

[Willie WY Wong]

On Thu, Apr 26, 2012 at 10:38:21AM -0400, Penguin Lover Doug Hunley squawked:
> On Thu, Apr 26, 2012 at 04:47, Helmut Jarausch
> <jarausch@igpm.rwth-aachen.de> wrote:
> > I am at glibc-2.15-r1 on AMD64 with no problems so far,
> 
> ditto here
> 

Hey guys, I think we've pretty much established that Michael is
running into an isolated problem or some strange edge case. 
Rubbing it in further really won't help, as he is quite clearly 
having an issue with two (or three) of his boxes despite y'all's
success on yours. So can we please stop with the "works for me" 
e-mails? 

At the very least, if you were to post one such, please make it
possibly useful for Michael by including your build options and such. 

Regards, 

W