[gentoo-user] glibc-2.12.1

[gentoo-user] glibc-2.12.1

[Alan McKinnon]

Hi,

Anyone successfully built and using glibc-2.12.1 yet?

I see the tree just pushed an update down from 2.11.2 to 2.12.1, and 
downgrading that package is decidedly non-trivial. Only comment I can find at 
this early stage is flameeye's blog, and this makes me quadruple nervous:




And if you say that “the new GLIBC works for me”, are you saying that the 
package itself builds or if it’s actually integrated correctly? Because, you 
know, I used to rebuild the whole system whenever I made a change to basic 
system packages when I maintained Gentoo/FreeBSD, and saying that it’s ready 
for ~arch when you haven’t even rebuilt the system (and you haven’t, or you 
would have noticed that m4 was broken) is definitely something I’d define as 
reckless and I’d venture to say you’re not good material to work on the 
quality assurance status.

“correctness” in the case of the system C library would be “it a t least 
leaves the system set building and running”; glibc 2.12 does not work this 
way.

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] glibc-2.12.1

[Graham Murray]

I have glibc-2.12.1 running on two ~x86 systems with no problems so far.

> Hi,
>
> Anyone successfully built and using glibc-2.12.1 yet?
>
> I see the tree just pushed an update down from 2.11.2 to 2.12.1, and 
> downgrading that package is decidedly non-trivial. Only comment I can find at 
> this early stage is flameeye's blog, and this makes me quadruple nervous:
>
>
>
>
> And if you say that “the new GLIBC works for me”, are you saying that the 
> package itself builds or if it’s actually integrated correctly? Because, you 
> know, I used to rebuild the whole system whenever I made a change to basic 
> system packages when I maintained Gentoo/FreeBSD, and saying that it’s ready 
> for ~arch when you haven’t even rebuilt the system (and you haven’t, or you 
> would have noticed that m4 was broken) is definitely something I’d define as 
> reckless and I’d venture to say you’re not good material to work on the 
> quality assurance status.
>
> “correctness” in the case of the system C library would be “it a t least 
> leaves the system set building and running”; glibc 2.12 does not work this 
> way.

Re: [gentoo-user] glibc-2.12.1

[Peter Ruskin]

On Tuesday 17 August 2010 09:33:09 Alan McKinnon wrote:
> Hi,
>
> Anyone successfully built and using glibc-2.12.1 yet?
>
> I see the tree just pushed an update down from 2.11.2 to 2.12.1,
> and downgrading that package is decidedly non-trivial. Only
> comment I can find at this early stage is flameeye's blog, and
> this makes me quadruple nervous:
>
>
>
>
> And if you say that “the new GLIBC works for me”, are you saying
> that the package itself builds or if it’s actually integrated
> correctly? Because, you know, I used to rebuild the whole system
> whenever I made a change to basic system packages when I
> maintained Gentoo/FreeBSD, and saying that it’s ready for ~arch
> when you haven’t even rebuilt the system (and you haven’t, or you
> would have noticed that m4 was broken) is definitely something
> I’d define as reckless and I’d venture to say you’re not good
> material to work on the quality assurance status.
>
> “correctness” in the case of the system C library would be “it a
> t least leaves the system set building and running”; glibc 2.12
> does not work this way.

OK here on ~amd64, but you got me worried so I emerged m4 to check 
and that went OK too.

-- 
Peter
========================================================================
Gentoo Linux: Portage 2.2_rc67			kernel-2.6.35-gentoo-r1
AMD Phenom(tm) 9950 Quad-Core Processor		gcc(Gentoo: 4.4.4-r1)
KDE: 3.5.10					Qt: 3.3.8b
========================================================================

Re: [gentoo-user] glibc-2.12.1

[Alan McKinnon]

On Tuesday 17 August 2010 15:21:35 Peter Ruskin wrote:
> On Tuesday 17 August 2010 09:33:09 Alan McKinnon wrote:
> > Hi,
> > 
> > Anyone successfully built and using glibc-2.12.1 yet?
> > 
> > I see the tree just pushed an update down from 2.11.2 to 2.12.1,
> > and downgrading that package is decidedly non-trivial. Only
> > comment I can find at this early stage is flameeye's blog, and
> > this makes me quadruple nervous:
> > 
> > 
> > 
> > 
> > And if you say that “the new GLIBC works for me”, are you saying
> > that the package itself builds or if it’s actually integrated
> > correctly? Because, you know, I used to rebuild the whole system
> > whenever I made a change to basic system packages when I
> > maintained Gentoo/FreeBSD, and saying that it’s ready for ~arch
> > when you haven’t even rebuilt the system (and you haven’t, or you
> > would have noticed that m4 was broken) is definitely something
> > I’d define as reckless and I’d venture to say you’re not good
> > material to work on the quality assurance status.
> > 
> > “correctness” in the case of the system C library would be “it a
> > t least leaves the system set building and running”; glibc 2.12
> > does not work this way.
> 
> OK here on ~amd64, but you got me worried so I emerged m4 to check
> and that went OK too.


I got a couple of replies, all like this one - positive.

Thanks, all. I'll start the update later on tonight and let 'er run.



-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] glibc-2.12.1

[Zhu Sha Zang]

[-- Attachment #1.1: Type: text/plain, Size: 7925 bytes --]

 Em 17-08-2010 12:34, Alan McKinnon escreveu:
> On Tuesday 17 August 2010 15:21:35 Peter Ruskin wrote:
>> On Tuesday 17 August 2010 09:33:09 Alan McKinnon wrote:
>>> Hi,
>>>
>>> Anyone successfully built and using glibc-2.12.1 yet?
>>>
>>> I see the tree just pushed an update down from 2.11.2 to 2.12.1,
>>> and downgrading that package is decidedly non-trivial. Only
>>> comment I can find at this early stage is flameeye's blog, and
>>> this makes me quadruple nervous:
>>>
>>>
>>>
>>>
>>> And if you say that “the new GLIBC works for me”, are you saying
>>> that the package itself builds or if it’s actually integrated
>>> correctly? Because, you know, I used to rebuild the whole system
>>> whenever I made a change to basic system packages when I
>>> maintained Gentoo/FreeBSD, and saying that it’s ready for ~arch
>>> when you haven’t even rebuilt the system (and you haven’t, or you
>>> would have noticed that m4 was broken) is definitely something
>>> I’d define as reckless and I’d venture to say you’re not good
>>> material to work on the quality assurance status.
>>>
>>> “correctness” in the case of the system C library would be “it a
>>> t least leaves the system set building and running”; glibc 2.12
>>> does not work this way.
>> OK here on ~amd64, but you got me worried so I emerged m4 to check
>> and that went OK too. 
>>
>
> I got a couple of replies, all like this one - positive.
>
> Thanks, all. I'll start the update later on tonight and let 'er run.
>
>
>
I'm trying to upgrade my glibc from 2.10.1-r1 to 2.10.1-r1 or 2.12.1 but
i'm blocked with a error on compilation in two c2q machines using x86_64
profile.

The CFLAGS and CHOST used are:

CHOST="x86_64-pc-linux-gnu"
CFLAGS="-march=core2 -mtune=generic -O2 -pipe"
CXXFLAGS="${CFLAGS}"

And the error in compilation:


../sysdeps/i386/i686/multiarch/strcmp.S: Assembler messages:
../sysdeps/i386/i686/multiarch/strcmp.S:78: Error: unrecognized symbol
type "gnu_indirect_function"
make[2]: ***
[/var/tmp/portage/sys-libs/glibc-2.12.1/work/build-x86-x86_64-pc-linux-gnu-nptl/string/strcmp.o]
Error 1
make[2]: *** Waiting for unfinished jobs....
../sysdeps/i386/i686/multiarch/strcspn.S: Assembler messages:
../sysdeps/i386/i686/multiarch/strcspn.S:78: Error: unrecognized symbol
type "gnu_indirect_function"
make[2]: ***
[/var/tmp/portage/sys-libs/glibc-2.12.1/work/build-x86-x86_64-pc-linux-gnu-nptl/string/strcspn.o]
Error 1
make[2]: Leaving directory
`/var/tmp/portage/sys-libs/glibc-2.12.1/work/glibc-2.12.1/string'
make[1]: *** [string/subdir_lib] Error 2
make[1]: Leaving directory
`/var/tmp/portage/sys-libs/glibc-2.12.1/work/glibc-2.12.1'
make: *** [all] Error 2
 * ERROR: sys-libs/glibc-2.12.1 failed:
 *   make for x86 failed
 *
 * Call stack:
 *           ebuild.sh, line   48:  Called src_compile
 *         environment, line 3826:  Called eblit-run 'src_compile'
 *         environment, line 1215:  Called eblit-glibc-src_compile
 *   src_compile.eblit, line  199:  Called src_compile
 *         environment, line 3826:  Called eblit-run 'src_compile'
 *         environment, line 1215:  Called eblit-glibc-src_compile
 *   src_compile.eblit, line  207:  Called toolchain-glibc_src_compile
 *   src_compile.eblit, line  123:  Called die
 * The specific snippet of code:
 *              emake || die "make for ${ABI} failed"
 *
 * If you need support, post the output of 'emerge --info
=sys-libs/glibc-2.12.1',
 * the complete build log and the output of 'emerge -pqv
=sys-libs/glibc-2.12.1'.
 * The complete build log is located at
'/var/tmp/portage/sys-libs/glibc-2.12.1/temp/build.log'.
 * The ebuild environment file is located at
'/var/tmp/portage/sys-libs/glibc-2.12.1/temp/environment'.
 * S: '/var/tmp/portage/sys-libs/glibc-2.12.1/work/glibc-2.12.1'


emerge info:

Portage 2.2_rc67 (default/linux/amd64/10.0, gcc-4.4.4, glibc-2.10.1-r1, 2.6.34-gentoo-r4-creta x86_64)
=================================================================
System uname: Linux-2.6.34-gentoo-r4-creta-x86_64-Intel-R-_Core-TM-2_Quad_CPU_Q6700_@_2.66GHz-with-gentoo-2.0.1
Timestamp of tree: Sun, 15 Aug 2010 15:30:01 +0000
distcc 3.1 x86_64-pc-linux-gnu [disabled]
ccache version 2.4 [enabled]
app-shells/bash:     4.0_p37
dev-lang/python:     2.6.5-r3, 3.1.2-r4
dev-util/ccache:     2.4-r7
sys-apps/baselayout: 2.0.1
sys-apps/openrc:     0.6.0-r1
sys-apps/sandbox:    2.2
sys-devel/autoconf:  2.65
sys-devel/automake:  1.10.3, 1.11.1
sys-devel/binutils:  2.18-r3, 2.20.1-r1
sys-devel/gcc:       4.4.3, 4.4.4-r1
sys-devel/gcc-config: 1.4.1
sys-devel/libtool:   2.2.6b
virtual/os-headers:  2.6.34
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="*"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=core2 -mtune=generic -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-march=core2 -mtune=generic -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="assume-digests autoaddcvs ccache distlocks emerge fixpackages news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch"
GENTOO_MIRRORS="http://gentoo.c3sl.ufpr.br/ http://www.las.ic.unicamp.br/pub/gentoo ftp://ftp.las.ic.unicamp.br/pub/gentoo ftp://ftp.ussg.iu.edu/pub/linux/gentoo"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
LINGUAS="pt_BR"
MAKEOPTS="-j8"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://dns.liec.ufscar.br/gentoo-portage"
USE="acl amd64 bash-completion berkdb bzip2 cli cracklib crypt cups cxx diskio dri fontforge fortran gd gdbm gpm iconv lapack libffi lm_sensors mfd-rewrites mmx modules mudflap multilib multislot multiuser ncurses nethack nis nls nptl nptlonly objc objc++ objc-gc openmp pam parse-clocks pcre perl pppd profile python python3 readline reflection rrdcgi session spl sse sse2 ssl subversion sysfs tcpd threads unicode utils xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="pt_BR" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga neomagic nv r128 radeon savage sis tdfx trident vesa via vmware voodoo" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" 
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY


I think that i have some misconfiguration in CFLAGS, but i don't know solve this error.

Some hint???

Thanks for now.


[-- Attachment #1.2: Type: text/html, Size: 9645 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-user] glibc-2.12.1

[William Kenworthy]

Hi Alan, a suggestion - for "mission critical" clone one of your systems
into a vm (dd), get it working, upgrade and test.

Or clone to a chroot and do the same.

Not quite 100% - but allows some peace of mind!

BillK

On Tue, 2010-08-17 at 17:34 +0200, Alan McKinnon wrote:
> On Tuesday 17 August 2010 15:21:35 Peter Ruskin wrote:
> > On Tuesday 17 August 2010 09:33:09 Alan McKinnon wrote:
> > > Hi,
> > > 
> > > Anyone successfully built and using glibc-2.12.1 yet?
> > > 
> > > I see the tree just pushed an update down from 2.11.2 to 2.12.1,
> > > and downgrading that package is decidedly non-trivial. Only
> > > comment I can find at this early stage is flameeye's blog, and
> > > this makes me quadruple nervous:
> > > 
> > > 
> > > 
> > > 
> > > And if you say that “the new GLIBC works for me”, are you saying
> > > that the package itself builds or if it’s actually integrated
> > > correctly? Because, you know, I used to rebuild the whole system
> > > whenever I made a change to basic system packages when I
> > > maintained Gentoo/FreeBSD, and saying that it’s ready for ~arch
> > > when you haven’t even rebuilt the system (and you haven’t, or you
> > > would have noticed that m4 was broken) is definitely something
> > > I’d define as reckless and I’d venture to say you’re not good
> > > material to work on the quality assurance status.
> > > 
> > > “correctness” in the case of the system C library would be “it a
> > > t least leaves the system set building and running”; glibc 2.12
> > > does not work this way.
> > 
> > OK here on ~amd64, but you got me worried so I emerged m4 to check
> > and that went OK too.
> 
> 
> I got a couple of replies, all like this one - positive.
> 
> Thanks, all. I'll start the update later on tonight and let 'er run.
> 
> 
> 

-- 
William Kenworthy <billk@iinet.net.au>
Home in Perth!

Re: [gentoo-user] glibc-2.12.1

[Alan McKinnon]

On Wednesday 18 August 2010 01:32:32 William Kenworthy wrote:
> Hi Alan, a suggestion - for "mission critical" clone one of your systems
> into a vm (dd), get it working, upgrade and test.
> 
> Or clone to a chroot and do the same.
> 
> Not quite 100% - but allows some peace of mind!


Hi Bill,


Good advice in general, but not really applicable to the specifics of my 
situation.

Being the dyed-in-the-wool gentoo fanatic that I am, I refuse to install it on 
production machines. I have 100+ of those and every one is different so things 
simply do not scale. Workload would increase hugely, not decrease, if I used 
gentoo.

It's my personal laptop that wants glibc upgraded. I use gentoo on all my 
personal machines and the -dev boxes too - USE makes it trivially easy to 
change the environment for whatever R&D is needed.

But for critical production machines? Not a flying chance in hell :-)
Too many times I've had to sort out the carnage from idiotic juniors who 
blindly run "emerge -uND world" and walk away thinking Unix always works like 
RedHat.

Gentoo requires far too much intelligence from it's sysadmin for maintenance 
to be automated - either by software means or by human means.

{I just know I'm gonna get flamed for this now :-)  }


> 
> BillK
> 
> On Tue, 2010-08-17 at 17:34 +0200, Alan McKinnon wrote:
> > On Tuesday 17 August 2010 15:21:35 Peter Ruskin wrote:
> > > On Tuesday 17 August 2010 09:33:09 Alan McKinnon wrote:
> > > > Hi,
> > > > 
> > > > Anyone successfully built and using glibc-2.12.1 yet?
> > > > 
> > > > I see the tree just pushed an update down from 2.11.2 to 2.12.1,
> > > > and downgrading that package is decidedly non-trivial. Only
> > > > comment I can find at this early stage is flameeye's blog, and
> > > > this makes me quadruple nervous:
> > > > 
> > > > 
> > > > 
> > > > 
> > > > And if you say that “the new GLIBC works for me”, are you saying
> > > > that the package itself builds or if it’s actually integrated
> > > > correctly? Because, you know, I used to rebuild the whole system
> > > > whenever I made a change to basic system packages when I
> > > > maintained Gentoo/FreeBSD, and saying that it’s ready for ~arch
> > > > when you haven’t even rebuilt the system (and you haven’t, or you
> > > > would have noticed that m4 was broken) is definitely something
> > > > I’d define as reckless and I’d venture to say you’re not good
> > > > material to work on the quality assurance status.
> > > > 
> > > > “correctness” in the case of the system C library would be “it a
> > > > t least leaves the system set building and running”; glibc 2.12
> > > > does not work this way.
> > > 
> > > OK here on ~amd64, but you got me worried so I emerged m4 to check
> > > and that went OK too.
> > 
> > I got a couple of replies, all like this one - positive.
> > 
> > Thanks, all. I'll start the update later on tonight and let 'er run.

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] glibc-2.12.1

[Neil Bothwick]

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

On Wed, 18 Aug 2010 16:05:05 +0200, Alan McKinnon wrote:

> But for critical production machines? Not a flying chance in hell :-)
> Too many times I've had to sort out the carnage from idiotic juniors
> who blindly run "emerge -uND world" and walk away thinking Unix always
> works like RedHat.

Why do you give these idiotic juniors the root password/sudo emerge rights?


-- 
Neil Bothwick

Top Oxymorons Number 28: Butt Head

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

Re: [gentoo-user] glibc-2.12.1

[Alan McKinnon]

Apparently, though unproven, at 14:49 on Thursday 19 August 2010, Neil 
Bothwick did opine thusly:

> On Wed, 18 Aug 2010 16:05:05 +0200, Alan McKinnon wrote:
> > But for critical production machines? Not a flying chance in hell :-)
> > Too many times I've had to sort out the carnage from idiotic juniors
> > who blindly run "emerge -uND world" and walk away thinking Unix always
> > works like RedHat.
> 
> Why do you give these idiotic juniors the root password/sudo emerge rights?


Because I have better things to do than log into 137 machines and do what it 
takes to update world on each one? Remember this ain't a cluster - only about 
20 of them share any kind of common usage.

Besides, if I don't give them some form of responsibility they will never 
become responsible.

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] glibc-2.12.1

[Neil Bothwick]

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

On Thu, 19 Aug 2010 17:55:02 +0200, Alan McKinnon wrote:

> Besides, if I don't give them some form of responsibility they will
> never become responsible.

Unfortunately, the converse is not necessarily true :(


-- 
Neil Bothwick

We have a equal opportunity Calculus class -- it's fully integrated.

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

Re: [gentoo-user] glibc-2.12.1

[Alan McKinnon]

Apparently, though unproven, at 19:28 on Thursday 19 August 2010, Neil 
Bothwick did opine thusly:

> On Thu, 19 Aug 2010 17:55:02 +0200, Alan McKinnon wrote:
> > Besides, if I don't give them some form of responsibility they will
> > never become responsible.
> 
> Unfortunately, the converse is not necessarily true :(

Yes, but the assertion that there is an HR department where I will send them 
after they demonstrate incompetence IS true :-)

I'd rather fix occasional controllable cock-ups rather than frequent 
uncontrollable ones



-- 
alan dot mckinnon at gmail dot com