[SOLVED] Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.
On Sat, Jun 23, 2012 at 6:08 PM, Michael Mol mike...@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.
-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.
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.
signature.asc
Description: PGP signature
Re: [SOLVED] Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.
On Wed, Jun 27, 2012 at 8:58 AM, Michael Mol mike...@gmail.com wrote:
On Sat, Jun 23, 2012 at 6:08 PM, Michael Mol mike...@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: [SOLVED] Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.
On Wed, Jun 27, 2012 at 12:12 PM, Neil Bothwick n...@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.
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. signature.asc Description: PGP signature
Re: [SOLVED] Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.
On Wed, Jun 27, 2012 at 1:05 PM, Neil Bothwick n...@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: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.
On Sat, Jun 23, 2012 at 12:37 AM, Michael Mol mike...@gmail.com wrote:
On Sat, Jun 2, 2012 at 11:56 PM, Michael Mol mike...@gmail.com wrote:
On Sat, Jun 2, 2012 at 11:34 PM, Dmitry Goncharov
dgoncha...@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 mike...@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
Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.
On Sat, Jun 2, 2012 at 11:56 PM, Michael Mol mike...@gmail.com wrote:
On Sat, Jun 2, 2012 at 11:34 PM, Dmitry Goncharov
dgoncha...@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 mike...@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.
On Sat, Apr 28, 2012 at 11:07 AM, Michael Mol mike...@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.
On Sat, Jun 02, 2012 at 10:52:12PM -0400, Michael Mol wrote:
On Sat, Apr 28, 2012 at 11:07 AM, Michael Mol mike...@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.
On Sat, Jun 2, 2012 at 11:34 PM, Dmitry Goncharov
dgoncha...@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 mike...@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.
On Sat, Jun 02, 2012 at 11:56:01PM -0400, Michael Mol wrote:
On Sat, Jun 2, 2012 at 11:34 PM, Dmitry Goncharov
dgoncha...@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 mike...@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.
On Sun, Jun 3, 2012 at 12:08 AM, Dmitry Goncharov
dgoncha...@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
dgoncha...@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 mike...@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.
On Apr 27, 2012 8:58 AM, Michael Mol mike...@gmail.com wrote:
On Thu, Apr 26, 2012 at 8:35 PM, Adam Carter adamcart...@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,
Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.
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 pa...@poluan.info wrote:
On Apr 27, 2012 8:58 AM, Michael Mol mike...@gmail.com wrote:
On Thu, Apr 26, 2012 at 8:35 PM, Adam Carter adamcart...@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,
Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.
On Apr 28, 2012 3:32 PM, Michael Mol mike...@gmail.com wrote: On Apr 28, 2012 3:14 AM, Pandu Poluan pa...@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,
Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.
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 pa...@poluan.info wrote: On Apr 28, 2012 3:32 PM, Michael Mol mike...@gmail.com wrote: On Apr 28, 2012 3:14 AM, Pandu Poluan pa...@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,
Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.
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 jarau...@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
RE: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.
From: Michael Mol [mailto:mike...@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.
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.
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.
On Thu, Apr 26, 2012 at 1:25 AM, Michael Mol mike...@gmail.com wrote: On Thu, Apr 26, 2012 at 1:16 AM, Michael Mol mike...@gmail.com wrote: On Thu, Apr 26, 2012 at 12:37 AM, Michael Mol mike...@gmail.com wrote: On Wed, Apr 25, 2012 at 11:50 PM, Canek Peláez Valdés can...@gmail.com wrote: On Wed, Apr 25, 2012 at 10:09 PM, Michael Mol mike...@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.
On Thu, Apr 26, 2012 at 19:40, Michael Mol mike...@gmail.com wrote: MAKEOPTS=-j1 didn't fix it. Off to find another solution. -- :wq Does sound like it's just you. I've been running with MAKEOPTS=-j13 and everything compiled and ran just fine. -- Joe
Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.
On Thu, Apr 26, 2012 at 04:47, Helmut Jarausch jarau...@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.hun...@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.
On Thu, Apr 26, 2012 at 10:34 AM, Qian Qiao qian.q...@gmail.com wrote: On Thu, Apr 26, 2012 at 19:40, Michael Mol mike...@gmail.com wrote: MAKEOPTS=-j1 didn't fix it. Off to find another solution. -- :wq Does sound like it's just you. I've been running with MAKEOPTS=-j13 and everything compiled and ran just fine. Checking to see if it's a distcc problem, now. If it is, it'll only be the third time I've ever had issues from distcc, and the first time a distcc issue resulted in a successful build of a package that broke things. -- :wq
Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.
On Thu, Apr 26, 2012 at 9:41 AM, Michael Mol mike...@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.
On Thu, Apr 26, 2012 at 22:41, Michael Mol mike...@gmail.com wrote: On Thu, Apr 26, 2012 at 10:34 AM, Qian Qiao qian.q...@gmail.com wrote: On Thu, Apr 26, 2012 at 19:40, Michael Mol mike...@gmail.com wrote: MAKEOPTS=-j1 didn't fix it. Off to find another solution. -- :wq Does sound like it's just you. I've been running with MAKEOPTS=-j13 and everything compiled and ran just fine. Checking to see if it's a distcc problem, now. If it is, it'll only be the third time I've ever had issues from distcc, and the first time a distcc issue resulted in a successful build of a package that broke things. 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.
On Thu, Apr 26, 2012 at 11:01 AM, Paul Hartman paul.hartman+gen...@gmail.com wrote: On Thu, Apr 26, 2012 at 9:41 AM, Michael Mol mike...@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.
On Thu, Apr 26, 2012 at 7:41 AM, Michael Mol mike...@gmail.com wrote:
On Thu, Apr 26, 2012 at 10:34 AM, Qian Qiao qian.q...@gmail.com wrote:
On Thu, Apr 26, 2012 at 19:40, Michael Mol mike...@gmail.com wrote:
MAKEOPTS=-j1 didn't fix it. Off to find another solution.
--
:wq
Does sound like it's just you. I've been running with MAKEOPTS=-j13
and everything compiled and ran just fine.
Checking to see if it's a distcc problem, now. If it is, it'll only be
the third time I've ever had issues from distcc, and the first time a
distcc issue resulted in a successful build of a package that broke
things.
--
:wq
Late to the party as I've been travelling. Running glibc-2.14.1-r3
here with no problems.
For the i7 i980x here's my make.conf stuff
FEATURES=buildpkg
EMERGE_DEFAULT_OPTS=--with-bdeps=y --jobs=5
MAKEOPTS=-j13 -l8
PORTAGE_NICENESS=5
PORTAGE_IONICE_COMMAND=ionice -c 3 -p \${PID}
This machine is mostly stable.
- Mark
Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.
On Thu, Apr 26, 2012 at 11:27 AM, Mark Knecht markkne...@gmail.com wrote:
On Thu, Apr 26, 2012 at 7:41 AM, Michael Mol mike...@gmail.com wrote:
On Thu, Apr 26, 2012 at 10:34 AM, Qian Qiao qian.q...@gmail.com wrote:
On Thu, Apr 26, 2012 at 19:40, Michael Mol mike...@gmail.com wrote:
MAKEOPTS=-j1 didn't fix it. Off to find another solution.
--
:wq
Does sound like it's just you. I've been running with MAKEOPTS=-j13
and everything compiled and ran just fine.
Checking to see if it's a distcc problem, now. If it is, it'll only be
the third time I've ever had issues from distcc, and the first time a
distcc issue resulted in a successful build of a package that broke
things.
--
:wq
Late to the party as I've been travelling. Running glibc-2.14.1-r3
here with no problems.
For the i7 i980x here's my make.conf stuff
FEATURES=buildpkg
EMERGE_DEFAULT_OPTS=--with-bdeps=y --jobs=5
MAKEOPTS=-j13 -l8
PORTAGE_NICENESS=5
PORTAGE_IONICE_COMMAND=ionice -c 3 -p \${PID}
This machine is mostly stable.
For comparison, here's the current setup on my Phenom 9650:
#expanded form of -march=native. Nothing special here. Noting this
here because people keep freaking out when they see it in-line.
SYS_CFLAGS_MARCH_NATIVE_EXP=-march=amdfam10 -mcx16 -msahf -mpopcnt
--param l1-cache-size=64 --param l1-cache-line-size=64 --param
l2-cache-size=512 -mtune=amdfam10
CFLAGS=${SYS_CFLAGS_MARCH_NATIVE_EXP} -O2 -pipe -ggdb3
CXXFLAGS=${CFLAGS}
FEATURES=splitdebug
MAKEOPTS=--jobs --load=5
EMERGE_DEFAULT_OPTS=--jobs --load-average=6 --verbose --tree
--with-bdeps=y --keep-going
--
:wq
Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.
On Thu, Apr 26, 2012 at 11:53 AM, Michael Mol mike...@gmail.com wrote:
On Thu, Apr 26, 2012 at 11:27 AM, Mark Knecht markkne...@gmail.com wrote:
On Thu, Apr 26, 2012 at 7:41 AM, Michael Mol mike...@gmail.com wrote:
On Thu, Apr 26, 2012 at 10:34 AM, Qian Qiao qian.q...@gmail.com wrote:
On Thu, Apr 26, 2012 at 19:40, Michael Mol mike...@gmail.com wrote:
MAKEOPTS=-j1 didn't fix it. Off to find another solution.
--
:wq
Does sound like it's just you. I've been running with MAKEOPTS=-j13
and everything compiled and ran just fine.
Checking to see if it's a distcc problem, now. If it is, it'll only be
the third time I've ever had issues from distcc, and the first time a
distcc issue resulted in a successful build of a package that broke
things.
--
:wq
Late to the party as I've been travelling. Running glibc-2.14.1-r3
here with no problems.
For the i7 i980x here's my make.conf stuff
FEATURES=buildpkg
EMERGE_DEFAULT_OPTS=--with-bdeps=y --jobs=5
MAKEOPTS=-j13 -l8
PORTAGE_NICENESS=5
PORTAGE_IONICE_COMMAND=ionice -c 3 -p \${PID}
This machine is mostly stable.
For comparison, here's the current setup on my Phenom 9650:
#expanded form of -march=native. Nothing special here. Noting this
here because people keep freaking out when they see it in-line.
SYS_CFLAGS_MARCH_NATIVE_EXP=-march=amdfam10 -mcx16 -msahf -mpopcnt
--param l1-cache-size=64 --param l1-cache-line-size=64 --param
l2-cache-size=512 -mtune=amdfam10
CFLAGS=${SYS_CFLAGS_MARCH_NATIVE_EXP} -O2 -pipe -ggdb3
CXXFLAGS=${CFLAGS}
FEATURES=splitdebug
MAKEOPTS=--jobs --load=5
EMERGE_DEFAULT_OPTS=--jobs --load-average=6 --verbose --tree
--with-bdeps=y --keep-going
OK, I got my atom server (which is amd64) to emerge glibc. The trick
was to reboot it; it had several weeks uptime, I suppose something
stale was in there. I rebooted it, emerged glibc, and everything is
fine.
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.
On Thu, Apr 26, 2012 at 2:20 PM, Canek Peláez Valdés can...@gmail.com wrote:
On Thu, Apr 26, 2012 at 11:53 AM, Michael Mol mike...@gmail.com wrote:
On Thu, Apr 26, 2012 at 11:27 AM, Mark Knecht markkne...@gmail.com wrote:
On Thu, Apr 26, 2012 at 7:41 AM, Michael Mol mike...@gmail.com wrote:
On Thu, Apr 26, 2012 at 10:34 AM, Qian Qiao qian.q...@gmail.com wrote:
On Thu, Apr 26, 2012 at 19:40, Michael Mol mike...@gmail.com wrote:
MAKEOPTS=-j1 didn't fix it. Off to find another solution.
--
:wq
Does sound like it's just you. I've been running with MAKEOPTS=-j13
and everything compiled and ran just fine.
Checking to see if it's a distcc problem, now. If it is, it'll only be
the third time I've ever had issues from distcc, and the first time a
distcc issue resulted in a successful build of a package that broke
things.
--
:wq
Late to the party as I've been travelling. Running glibc-2.14.1-r3
here with no problems.
For the i7 i980x here's my make.conf stuff
FEATURES=buildpkg
EMERGE_DEFAULT_OPTS=--with-bdeps=y --jobs=5
MAKEOPTS=-j13 -l8
PORTAGE_NICENESS=5
PORTAGE_IONICE_COMMAND=ionice -c 3 -p \${PID}
This machine is mostly stable.
For comparison, here's the current setup on my Phenom 9650:
#expanded form of -march=native. Nothing special here. Noting this
here because people keep freaking out when they see it in-line.
SYS_CFLAGS_MARCH_NATIVE_EXP=-march=amdfam10 -mcx16 -msahf -mpopcnt
--param l1-cache-size=64 --param l1-cache-line-size=64 --param
l2-cache-size=512 -mtune=amdfam10
CFLAGS=${SYS_CFLAGS_MARCH_NATIVE_EXP} -O2 -pipe -ggdb3
CXXFLAGS=${CFLAGS}
FEATURES=splitdebug
MAKEOPTS=--jobs --load=5
EMERGE_DEFAULT_OPTS=--jobs --load-average=6 --verbose --tree
--with-bdeps=y --keep-going
OK, I got my atom server (which is amd64) to emerge glibc. The trick
was to reboot it; it had several weeks uptime, I suppose something
stale was in there. I rebooted it, emerged glibc, and everything is
fine.
Good to know. I'm still trying to figure out why emerging glibc,
specifically, breaks/broke two out of three systems for me.
--
:wq
Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.
On Thu, Apr 26, 2012 at 2:26 PM, Michael Mol mike...@gmail.com wrote:
On Thu, Apr 26, 2012 at 2:20 PM, Canek Peláez Valdés can...@gmail.com wrote:
On Thu, Apr 26, 2012 at 11:53 AM, Michael Mol mike...@gmail.com wrote:
On Thu, Apr 26, 2012 at 11:27 AM, Mark Knecht markkne...@gmail.com wrote:
On Thu, Apr 26, 2012 at 7:41 AM, Michael Mol mike...@gmail.com wrote:
On Thu, Apr 26, 2012 at 10:34 AM, Qian Qiao qian.q...@gmail.com wrote:
On Thu, Apr 26, 2012 at 19:40, Michael Mol mike...@gmail.com wrote:
MAKEOPTS=-j1 didn't fix it. Off to find another solution.
--
:wq
Does sound like it's just you. I've been running with MAKEOPTS=-j13
and everything compiled and ran just fine.
Checking to see if it's a distcc problem, now. If it is, it'll only be
the third time I've ever had issues from distcc, and the first time a
distcc issue resulted in a successful build of a package that broke
things.
--
:wq
Late to the party as I've been travelling. Running glibc-2.14.1-r3
here with no problems.
For the i7 i980x here's my make.conf stuff
FEATURES=buildpkg
EMERGE_DEFAULT_OPTS=--with-bdeps=y --jobs=5
MAKEOPTS=-j13 -l8
PORTAGE_NICENESS=5
PORTAGE_IONICE_COMMAND=ionice -c 3 -p \${PID}
This machine is mostly stable.
For comparison, here's the current setup on my Phenom 9650:
#expanded form of -march=native. Nothing special here. Noting this
here because people keep freaking out when they see it in-line.
SYS_CFLAGS_MARCH_NATIVE_EXP=-march=amdfam10 -mcx16 -msahf -mpopcnt
--param l1-cache-size=64 --param l1-cache-line-size=64 --param
l2-cache-size=512 -mtune=amdfam10
CFLAGS=${SYS_CFLAGS_MARCH_NATIVE_EXP} -O2 -pipe -ggdb3
CXXFLAGS=${CFLAGS}
FEATURES=splitdebug
MAKEOPTS=--jobs --load=5
EMERGE_DEFAULT_OPTS=--jobs --load-average=6 --verbose --tree
--with-bdeps=y --keep-going
OK, I got my atom server (which is amd64) to emerge glibc. The trick
was to reboot it; it had several weeks uptime, I suppose something
stale was in there. I rebooted it, emerged glibc, and everything is
fine.
Good to know. I'm still trying to figure out why emerging glibc,
specifically, breaks/broke two out of three systems for me.
I don't know what's left to try. All the libraries warned about below
are owned by glibc, and I've re-emerged binutils many times already.
Some of the output from gdb:
Reading symbols from /bash...(no debugging symbols found)...done.
[New LWP 6049]
warning: Can't read pathname for load map: Input/output error.
warning: .dynamic section for /lib64/libdl.so.2 is not at the
expected address (wrong library or version mismatch?)
warning: .dynamic section for /lib64/libc.so.6 is not at the
expected address (wrong library or version mismatch?)
warning: .dynamic section for /lib64/ld-linux-x86-64.so.2 is not at
the expected address (wrong library or version mismatch?)
warning: .dynamic section for /lib64/libnss_files.so.2 is not at the
expected address (wrong library or version mismatch?)
Core was generated by `bash'.
Program terminated with signal 11, Segmentation fault.
#0 0x7f9a94dbdc40 in ?? ()
--
:wq
Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.
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 mike...@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 **!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
Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.
Am Donnerstag, 26. April 2012, 12:53:28 schrieb Michael Mol:
On Thu, Apr 26, 2012 at 11:27 AM, Mark Knecht markkne...@gmail.com wrote:
On Thu, Apr 26, 2012 at 7:41 AM, Michael Mol mike...@gmail.com wrote:
On Thu, Apr 26, 2012 at 10:34 AM, Qian Qiao qian.q...@gmail.com wrote:
On Thu, Apr 26, 2012 at 19:40, Michael Mol mike...@gmail.com wrote:
MAKEOPTS=-j1 didn't fix it. Off to find another solution.
--
:wq
Does sound like it's just you. I've been running with MAKEOPTS=-j13
and everything compiled and ran just fine.
Checking to see if it's a distcc problem, now. If it is, it'll only be
the third time I've ever had issues from distcc, and the first time a
distcc issue resulted in a successful build of a package that broke
things.
--
:wq
Late to the party as I've been travelling. Running glibc-2.14.1-r3
here with no problems.
For the i7 i980x here's my make.conf stuff
FEATURES=buildpkg
EMERGE_DEFAULT_OPTS=--with-bdeps=y --jobs=5
MAKEOPTS=-j13 -l8
PORTAGE_NICENESS=5
PORTAGE_IONICE_COMMAND=ionice -c 3 -p \${PID}
This machine is mostly stable.
For comparison, here's the current setup on my Phenom 9650:
#expanded form of -march=native. Nothing special here. Noting this
here because people keep freaking out when they see it in-line.
SYS_CFLAGS_MARCH_NATIVE_EXP=-march=amdfam10 -mcx16 -msahf -mpopcnt
--param l1-cache-size=64 --param l1-cache-line-size=64 --param
l2-cache-size=512 -mtune=amdfam10
CFLAGS=${SYS_CFLAGS_MARCH_NATIVE_EXP} -O2 -pipe -ggdb3
CXXFLAGS=${CFLAGS}
FEATURES=splitdebug
MAKEOPTS=--jobs --load=5
EMERGE_DEFAULT_OPTS=--jobs --load-average=6 --verbose --tree
--with-bdeps=y --keep-going
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.
#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.
On Thu, Apr 26, 2012 at 8:35 PM, Adam Carter adamcart...@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
[gentoo-user] 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
Re: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.
On Wed, Apr 25, 2012 at 10:09 PM, Michael Mol mike...@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.
On Wed, Apr 25, 2012 at 11:50 PM, Canek Peláez Valdés can...@gmail.com wrote: On Wed, Apr 25, 2012 at 10:09 PM, Michael Mol mike...@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.
On Wed, Apr 25, 2012 at 11:50 PM, Canek Peláez Valdés can...@gmail.com wrote: On Wed, Apr 25, 2012 at 10:09 PM, Michael Mol mike...@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.
On Thu, Apr 26, 2012 at 12:37 AM, Michael Mol mike...@gmail.com wrote: On Wed, Apr 25, 2012 at 11:50 PM, Canek Peláez Valdés can...@gmail.com wrote: On Wed, Apr 25, 2012 at 10:09 PM, Michael Mol mike...@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.
On Thu, Apr 26, 2012 at 1:16 AM, Michael Mol mike...@gmail.com wrote: On Thu, Apr 26, 2012 at 12:37 AM, Michael Mol mike...@gmail.com wrote: On Wed, Apr 25, 2012 at 11:50 PM, Canek Peláez Valdés can...@gmail.com wrote: On Wed, Apr 25, 2012 at 10:09 PM, Michael Mol mike...@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
