FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo User

 
 
LinkBack Thread Tools
 
Old 08-17-2010, 08:33 AM
Alan McKinnon
 
Default glibc-2.12.1

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
 
Old 08-17-2010, 09:56 AM
Graham Murray
 
Default glibc-2.12.1

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.
 
Old 08-17-2010, 01:21 PM
Peter Ruskin
 
Default glibc-2.12.1

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
================================================== ======================
 
Old 08-17-2010, 03:34 PM
Alan McKinnon
 
Default glibc-2.12.1

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
 
Old 08-17-2010, 04:30 PM
Zhu Sha Zang
 
Default glibc-2.12.1

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_use
r 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.
 
Old 08-17-2010, 11:32 PM
William Kenworthy
 
Default glibc-2.12.1

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!
 
Old 08-18-2010, 02:05 PM
Alan McKinnon
 
Default glibc-2.12.1

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
 
Old 08-19-2010, 12:49 PM
Neil Bothwick
 
Default glibc-2.12.1

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
 
Old 08-19-2010, 03:55 PM
Alan McKinnon
 
Default glibc-2.12.1

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
 
Old 08-19-2010, 05:28 PM
Neil Bothwick
 
Default glibc-2.12.1

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.
 

Thread Tools




All times are GMT. The time now is 01:42 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org