Re: [gentoo-user] glibc 2.12.1-r1 seems to not be working correctly
cov...@ccs.covici.com writes: Hi. I am running the unstable gentoo 32-bit and today I emerged -- amoung other packages in a system update -- glibc-2.12.1-r1, however after doing this at least one package had an undefined reference to S_ISCHR. I tried to downgrade glibc, but apparently this is not supported and I am a bit stumped as to how to fix this problem. Looks like a real bad problem, I'm glad I did not update yet. http://blog.flameeyes.eu/2010/08/18/compounded-issues-in-glibc-2-12 has some explanation on this. I wonder how this glibx version did make it into ~arch. Any ideas on this would be appreciated. Don't know. Maybe wait a little and see if another new glibc fixes this, or the packages having issues with the new glibc might get updated. Wonko
Re: [gentoo-user] glibc 2.12.1-r1 seems to not be working correctly
On 8/22/10, cov...@ccs.covici.com cov...@ccs.covici.com wrote: Hi. I am running the unstable gentoo 32-bit and today I emerged -- amoung other packages in a system update -- glibc-2.12.1-r1, however after doing this at least one package had an undefined reference to S_ISCHR. I tried to downgrade glibc, but apparently this is not supported and I am a bit stumped as to how to fix this problem. Any ideas on this would be appreciated. Which package is failing? Please check if it is already reported, and if not then please report a new bug, and if possible make it block this tracker bug: http://bugs.gentoo.org/show_bug.cgi?id=331665 A wild guess out of the blue would be that the error could be simply a missing include of stat.h in the package's sources. But there might be other omissions as well, so please provide more info. I think that unless API/ABIs were changed then the older, already installed version should still work just fine, as then the missing includes would only affect compile-time situation. -- Arttu V. -- Running Gentoo is like running with scissors
Re: [gentoo-user] glibc 2.12.1-r1 seems to not be working correctly
Arttu V. arttu...@gmail.com wrote: On 8/22/10, cov...@ccs.covici.com cov...@ccs.covici.com wrote: Hi. I am running the unstable gentoo 32-bit and today I emerged -- amoung other packages in a system update -- glibc-2.12.1-r1, however after doing this at least one package had an undefined reference to S_ISCHR. I tried to downgrade glibc, but apparently this is not supported and I am a bit stumped as to how to fix this problem. Any ideas on this would be appreciated. Which package is failing? Please check if it is already reported, and if not then please report a new bug, and if possible make it block this tracker bug: http://bugs.gentoo.org/show_bug.cgi?id=331665 A wild guess out of the blue would be that the error could be simply a missing include of stat.h in the package's sources. But there might be other omissions as well, so please provide more info. I think that unless API/ABIs were changed then the older, already installed version should still work just fine, as then the missing includes would only affect compile-time situation. OK, I will check on that -- I am thinking that for that package a missing include will fix this, but I could shoot whoever broke this without thinking at all. I wonder if the failure of php to compile because my_compiler.h is missing has something to do with this also? -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] glibc 2.12.1-r1 seems to not be working correctly
Apparently, though unproven, at 15:29 on Sunday 22 August 2010, Arttu V. did opine thusly: On 8/22/10, cov...@ccs.covici.com cov...@ccs.covici.com wrote: Hi. I am running the unstable gentoo 32-bit and today I emerged -- amoung other packages in a system update -- glibc-2.12.1-r1, however after doing this at least one package had an undefined reference to S_ISCHR. I tried to downgrade glibc, but apparently this is not supported and I am a bit stumped as to how to fix this problem. Any ideas on this would be appreciated. Which package is failing? Please check if it is already reported, and if not then please report a new bug, and if possible make it block this tracker bug: http://bugs.gentoo.org/show_bug.cgi?id=331665 A wild guess out of the blue would be that the error could be simply a missing include of stat.h in the package's sources. But there might be other omissions as well, so please provide more info. I think that unless API/ABIs were changed then the older, already installed version should still work just fine, as then the missing includes would only affect compile-time situation. There is a way to downgrade for the brave. quickpkg glibc move the 2.11.? version ebuild you want to your local overlay. Edit it and find the check that disallows downgrades. Comment it out. Mask glibc2.12 update glibc At this point it's probably very wise to rebuild at least system, then revdep- rebuild. Note that rebuilding system might fail in which case you are really up the creek. Feel free to rip to pieces the dev that committed this version. It could not possibly have undergone decent testing -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] glibc 2.12.1-r1 seems to not be working correctly
Alan McKinnon alan.mckin...@gmail.com wrote: Apparently, though unproven, at 15:29 on Sunday 22 August 2010, Arttu V. did opine thusly: On 8/22/10, cov...@ccs.covici.com cov...@ccs.covici.com wrote: Hi. I am running the unstable gentoo 32-bit and today I emerged -- amoung other packages in a system update -- glibc-2.12.1-r1, however after doing this at least one package had an undefined reference to S_ISCHR. I tried to downgrade glibc, but apparently this is not supported and I am a bit stumped as to how to fix this problem. Any ideas on this would be appreciated. Which package is failing? Please check if it is already reported, and if not then please report a new bug, and if possible make it block this tracker bug: http://bugs.gentoo.org/show_bug.cgi?id=331665 A wild guess out of the blue would be that the error could be simply a missing include of stat.h in the package's sources. But there might be other omissions as well, so please provide more info. I think that unless API/ABIs were changed then the older, already installed version should still work just fine, as then the missing includes would only affect compile-time situation. There is a way to downgrade for the brave. quickpkg glibc move the 2.11.? version ebuild you want to your local overlay. Edit it and find the check that disallows downgrades. Comment it out. Mask glibc2.12 update glibc At this point it's probably very wise to rebuild at least system, then revdep- rebuild. Note that rebuilding system might fail in which case you are really up the creek. Feel free to rip to pieces the dev that committed this version. It could not possibly have undergone decent testing I have another idea -- what would I have to restore from backup to completely cancel the entire update process I have done since yesterday -- and then I could mask off the bad glibc and be back to something at least somewhat consistent? -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] glibc 2.12.1-r1 seems to not be working correctly
Apparently, though unproven, at 20:57 on Sunday 22 August 2010, cov...@ccs.covici.com did opine thusly: There is a way to downgrade for the brave. quickpkg glibc move the 2.11.? version ebuild you want to your local overlay. Edit it and find the check that disallows downgrades. Comment it out. Mask glibc2.12 update glibc At this point it's probably very wise to rebuild at least system, then revdep- rebuild. Note that rebuilding system might fail in which case you are really up the creek. Feel free to rip to pieces the dev that committed this version. It could not possibly have undergone decent testing I have another idea -- what would I have to restore from backup to completely cancel the entire update process I have done since yesterday -- and then I could mask off the bad glibc and be back to something at least somewhat consistent? I too have another idea - look at emerge.log and tell us what you emerged since yesterday. Then restore those packages. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] glibc 2.12.1-r1 seems to not be working correctly
Alan McKinnon alan.mckin...@gmail.com wrote: Apparently, though unproven, at 20:57 on Sunday 22 August 2010, cov...@ccs.covici.com did opine thusly: There is a way to downgrade for the brave. quickpkg glibc move the 2.11.? version ebuild you want to your local overlay. Edit it and find the check that disallows downgrades. Comment it out. Mask glibc2.12 update glibc At this point it's probably very wise to rebuild at least system, then revdep- rebuild. Note that rebuilding system might fail in which case you are really up the creek. Feel free to rip to pieces the dev that committed this version. It could not possibly have undergone decent testing I have another idea -- what would I have to restore from backup to completely cancel the entire update process I have done since yesterday -- and then I could mask off the bad glibc and be back to something at least somewhat consistent? I too have another idea - look at emerge.log and tell us what you emerged since yesterday. Then restore those packages. -- alan dot mckinnon at gmail dot com If I tried that -- how would I downgrade glibc in the process -- I am sure I could figure out all the packages, but that downgrade scares me -- would I do the packages in reverse order, or what? I also changed my gcc before this update, I could certainly reverse that as well. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] glibc 2.12.1-r1 seems to not be working correctly
Apparently, though unproven, at 21:44 on Sunday 22 August 2010, cov...@ccs.covici.com did opine thusly: Alan McKinnon alan.mckin...@gmail.com wrote: Apparently, though unproven, at 20:57 on Sunday 22 August 2010, cov...@ccs.covici.com did opine thusly: There is a way to downgrade for the brave. quickpkg glibc move the 2.11.? version ebuild you want to your local overlay. Edit it and find the check that disallows downgrades. Comment it out. Mask glibc2.12 update glibc At this point it's probably very wise to rebuild at least system, then revdep- rebuild. Note that rebuilding system might fail in which case you are really up the creek. Feel free to rip to pieces the dev that committed this version. It could not possibly have undergone decent testing I have another idea -- what would I have to restore from backup to completely cancel the entire update process I have done since yesterday -- and then I could mask off the bad glibc and be back to something at least somewhat consistent? I too have another idea - look at emerge.log and tell us what you emerged since yesterday. Then restore those packages. If I tried that -- how would I downgrade glibc in the process -- I am sure I could figure out all the packages, but that downgrade scares me -- would I do the packages in reverse order, or what? I also changed my gcc before this update, I could certainly reverse that as well. It all depends on what tools you have available and how many packages were upgraded between yesterday and today. If you have tarballs for at least system in your packages dir, then just merge the old ones back. If not, then downgrade glibc and either emerge -e system or run revdep-rebuild. gcc is not a major issue, it simply builds runnable code and links to other stuff. As long as the ABI didn't change, and it didn't, gcc will not cause any relevant problems. The real problem is glibc which provides the C library. Almost everything links to that and it's interfaces can and do change. So packages built since that upgrade may well break with a downgrade. But like I said the best approach will depend on what packages are involved and you still haven't provided that list. I used to have a crystal ball that could gaze into your mind and your disk to find these answer, but ironically it too is now broken by the very same glibc upgrade you are dealing with. So you must look into this yourself. However, it's not all bad news - at least my fee to you will not increase. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] glibc 2.12.1-r1 seems to not be working correctly
On Sunday 22 August 2010, cov...@ccs.covici.com wrote: Alan McKinnon alan.mckin...@gmail.com wrote: Apparently, though unproven, at 20:57 on Sunday 22 August 2010, cov...@ccs.covici.com did opine thusly: There is a way to downgrade for the brave. quickpkg glibc move the 2.11.? version ebuild you want to your local overlay. Edit it and find the check that disallows downgrades. Comment it out. Mask glibc2.12 update glibc At this point it's probably very wise to rebuild at least system, then revdep- rebuild. Note that rebuilding system might fail in which case you are really up the creek. Feel free to rip to pieces the dev that committed this version. It could not possibly have undergone decent testing I have another idea -- what would I have to restore from backup to completely cancel the entire update process I have done since yesterday -- and then I could mask off the bad glibc and be back to something at least somewhat consistent? I too have another idea - look at emerge.log and tell us what you emerged since yesterday. Then restore those packages. If I tried that -- how would I downgrade glibc in the process -- I am sure I could figure out all the packages, but that downgrade scares me -- would I do the packages in reverse order, or what? I also changed my gcc before this update, I could certainly reverse that as well. you can also leave that glibc version in place. Only a few packages are affected, most are fixed already. Just sync and retry the failing package. No need to downgrade glibc and recompile a bunch of packages. Besides, between 2.12.1 and 2.12.0 you should not need to recompile anything.
Re: [gentoo-user] glibc-2.12.1
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
Re: [gentoo-user] 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 signature.asc Description: PGP signature
Re: [gentoo-user] 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
Re: [gentoo-user] 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. signature.asc Description: PGP signature
Re: [gentoo-user] 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.
Re: [gentoo-user] 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
Re: [gentoo-user] 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_q67...@_2.66ghz-with-gentoo-2.0.1
Timestamp of tree: Sun, 15 Aug 2010 15:30:01 +
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
Re: [gentoo-user] 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 bi...@iinet.net.au Home in Perth!
