Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: User

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

 

 

First page Previous page 1 2 Next page Last page  View All Gentoo user RSS feed   Index | Next | Previous | View Threaded


mikemol at gmail

Apr 25, 2012, 8:09 PM

Post #1 of 40 (1607 views)
Permalink
Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.

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


caneko at gmail

Apr 25, 2012, 8:50 PM

Post #2 of 40 (1542 views)
Permalink
Re: Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker. [In reply to]

On Wed, Apr 25, 2012 at 10:09 PM, Michael Mol <mikemol [at] gmail> 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


mikemol at gmail

Apr 25, 2012, 9:10 PM

Post #3 of 40 (1548 views)
Permalink
Re: Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker. [In reply to]

On Wed, Apr 25, 2012 at 11:50 PM, Canek Peláez Valdés <caneko [at] gmail> wrote:
> On Wed, Apr 25, 2012 at 10:09 PM, Michael Mol <mikemol [at] gmail> 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


mikemol at gmail

Apr 25, 2012, 9:37 PM

Post #4 of 40 (1548 views)
Permalink
Re: Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker. [In reply to]

On Wed, Apr 25, 2012 at 11:50 PM, Canek Peláez Valdés <caneko [at] gmail> wrote:
> On Wed, Apr 25, 2012 at 10:09 PM, Michael Mol <mikemol [at] gmail> 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


mikemol at gmail

Apr 25, 2012, 10:16 PM

Post #5 of 40 (1547 views)
Permalink
Re: Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker. [In reply to]

On Thu, Apr 26, 2012 at 12:37 AM, Michael Mol <mikemol [at] gmail> wrote:
> On Wed, Apr 25, 2012 at 11:50 PM, Canek Peláez Valdés <caneko [at] gmail> wrote:
>> On Wed, Apr 25, 2012 at 10:09 PM, Michael Mol <mikemol [at] gmail> 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


mikemol at gmail

Apr 25, 2012, 10:25 PM

Post #6 of 40 (1541 views)
Permalink
Re: Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker. [In reply to]

On Thu, Apr 26, 2012 at 1:16 AM, Michael Mol <mikemol [at] gmail> wrote:
> On Thu, Apr 26, 2012 at 12:37 AM, Michael Mol <mikemol [at] gmail> wrote:
>> On Wed, Apr 25, 2012 at 11:50 PM, Canek Peláez Valdés <caneko [at] gmail> wrote:
>>> On Wed, Apr 25, 2012 at 10:09 PM, Michael Mol <mikemol [at] gmail> 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


realnc at gmail

Apr 26, 2012, 12:01 AM

Post #7 of 40 (1546 views)
Permalink
Re: Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker. [In reply to]

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).


rdalek1967 at gmail

Apr 26, 2012, 12:17 AM

Post #8 of 40 (1543 views)
Permalink
Re: Re: Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker. [In reply to]

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"


jarausch at igpm

Apr 26, 2012, 1:47 AM

Post #9 of 40 (1547 views)
Permalink
Re: Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker. [In reply to]

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.


napalm at squareownz

Apr 26, 2012, 3:06 AM

Post #10 of 40 (1546 views)
Permalink
Re: Re: Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker. [In reply to]

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.


alyf at alyf

Apr 26, 2012, 3:51 AM

Post #11 of 40 (1546 views)
Permalink
Re: Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker. [In reply to]

> 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


mikemol at gmail

Apr 26, 2012, 4:40 AM

Post #12 of 40 (1544 views)
Permalink
Re: Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker. [In reply to]

On Thu, Apr 26, 2012 at 1:25 AM, Michael Mol <mikemol [at] gmail> wrote:
> On Thu, Apr 26, 2012 at 1:16 AM, Michael Mol <mikemol [at] gmail> wrote:
>> On Thu, Apr 26, 2012 at 12:37 AM, Michael Mol <mikemol [at] gmail> wrote:
>>> On Wed, Apr 25, 2012 at 11:50 PM, Canek Peláez Valdés <caneko [at] gmail> wrote:
>>>> On Wed, Apr 25, 2012 at 10:09 PM, Michael Mol <mikemol [at] gmail> 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


qian.qiao at gmail

Apr 26, 2012, 7:34 AM

Post #13 of 40 (1555 views)
Permalink
Re: Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker. [In reply to]

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


doug.hunley at gmail

Apr 26, 2012, 7:38 AM

Post #14 of 40 (1545 views)
Permalink
Re: Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker. [In reply to]

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

ditto here

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


mikemol at gmail

Apr 26, 2012, 7:41 AM

Post #15 of 40 (1543 views)
Permalink
Re: Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker. [In reply to]

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


paul.hartman+gentoo at gmail

Apr 26, 2012, 8:01 AM

Post #16 of 40 (1543 views)
Permalink
Re: Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker. [In reply to]

On Thu, Apr 26, 2012 at 9:41 AM, Michael Mol <mikemol [at] gmail> 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?


qian.qiao at gmail

Apr 26, 2012, 8:04 AM

Post #17 of 40 (1543 views)
Permalink
Re: Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker. [In reply to]

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


mikemol at gmail

Apr 26, 2012, 8:24 AM

Post #18 of 40 (1541 views)
Permalink
Re: Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker. [In reply to]

On Thu, Apr 26, 2012 at 11:01 AM, Paul Hartman
<paul.hartman+gentoo [at] gmail> wrote:
> On Thu, Apr 26, 2012 at 9:41 AM, Michael Mol <mikemol [at] gmail> 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


markknecht at gmail

Apr 26, 2012, 8:27 AM

Post #19 of 40 (1544 views)
Permalink
Re: Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker. [In reply to]

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


mikemol at gmail

Apr 26, 2012, 9:53 AM

Post #20 of 40 (1541 views)
Permalink
Re: Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker. [In reply to]

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


caneko at gmail

Apr 26, 2012, 11:20 AM

Post #21 of 40 (1541 views)
Permalink
Re: Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker. [In reply to]

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


mikemol at gmail

Apr 26, 2012, 11:26 AM

Post #22 of 40 (1545 views)
Permalink
Re: Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker. [In reply to]

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


mikemol at gmail

Apr 26, 2012, 12:06 PM

Post #23 of 40 (1551 views)
Permalink
Re: Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker. [In reply to]

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


volkerarmin at googlemail

Apr 26, 2012, 1:30 PM

Post #24 of 40 (1543 views)
Permalink
Re: Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker. [In reply to]

Am Mittwoch, 25. April 2012, 22:50:53 schrieb Canek Pelez Valds:
> On Wed, Apr 25, 2012 at 10:09 PM, Michael Mol <mikemol [at] gmail> 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


volkerarmin at googlemail

Apr 26, 2012, 1:35 PM

Post #25 of 40 (1549 views)
Permalink
Re: Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker. [In reply to]

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

First page Previous page 1 2 Next page Last page  View All Gentoo user RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.