After being hit by bug 138446 , I had to downgrade gcc and glibc. (This move has since been forced by the profile (ppc64, 32ul) ). However, the glibc compilation fails, with the error message below.
Inbetween, I found bug 126161 and the Jakub Moc's comment : "NEVER (!!!) downgrade glibc... ". I guess ther is a good reason (which one ?). If it's the case, portage should be fixed to forbid any glibc downgrade.
What is the way out for people trapped in this impossible profile change ? Reinstalling from scratch ? Forced glibc and gcc upgrade ?
/var/tmp/portage/glibc-2.3.6-r3/work/build-default-powerpc-unknown-linux-gnu-nptl/sunrpc/rpcgen: /var/tmp/portage/glibc-2.3.6-r3/work/build-default-powerpc-unknown-linux-gnu-nptl/libc.so.6: version `GLIBC_2.4' not found (required by /usr/lib/libsandbox.so)
make: *** [/var/tmp/portage/glibc-2.3.6-r3/work/build-default-powerpc-unknown-linux-gnu-nptl/sunrpc/xbootparam_prot.stmp] Error 1
make: *** Waiting for unfinished jobs....
make: Leaving directory `/var/tmp/portage/glibc-2.3.6-r3/work/glibc-2.3.6/sunrpc'
make: *** [sunrpc/others] Error 2
make: Leaving directory `/var/tmp/portage/glibc-2.3.6-r3/work/glibc-2.3.6'
make: *** [all] Error 2
!!! ERROR: sys-libs/glibc-2.3.6-r3 failed.
ebuild.sh, line 1539: Called dyn_compile
ebuild.sh, line 939: Called src_compile
glibc-2.3.6-r3.ebuild, line 1238: Called toolchain-glibc_src_compile
glibc-2.3.6-r3.ebuild, line 261: Called die
!!! make for default failed
!!! If you need support, post the topmost build error, and the call stack if relevant.
Downgrading glibc is always impossible, so... shrug, fix the real bug, don't downgrade. Sorry.
If someone masked gcc-4.1, then glibc-2.4 should have been masked as well as it depends on it - but I see glibc-2.4-r3 and gcc-4.1.1 keyworded stable on ppc, so really I don't grok what are you talking about.
(In reply to comment #1)
> If someone masked gcc-4.1, then glibc-2.4 should have been masked as well as it
> depends on it - but I see glibc-2.4-r3 and gcc-4.1.1 keyworded stable on ppc,
> so really I don't grok what are you talking about.
It was a 32ul problem : on ppc, both have been marked stable and masked in the 2006.0 profile simultaneously. They have only been masked later in the 32ul ppc64 profile, hence this bug. I've upgraded to gcc 4.1 and glibc 2.4, met bug 138446, which has been "solved" by this change in the 32ul ppc64 profile, hence the "impossible but necessary downgrade" for some people.
(In reply to comment #1)
> Downgrading glibc is always impossible, so...
Sad, but I guess the lif is sometimes sad...
> shrug, fix the real bug, don't
> downgrade. Sorry.
An acceptable resolution (for me) would be unmasking gcc 4.1 and glibc 2.4 , in an experimental 2006.1 profile, like in the ppc32 2006.1 profile.
Do you still object to the dependency of bug 138446 to this bug ? Bug 138446 has basically been solved for everyone, except for the people like me, because of this impossible but necessary downgrade.
(In reply to comment #3)
> Do you still object to the dependency of bug 138446 to this bug ? Bug 138446
> has basically been solved for everyone, except for the people like me, because
> of this impossible but necessary downgrade.
Erm, what dependency? I haven't noticed any, adding it now. :)
Looks like this is related to http://article.gmane.org/gmane.linux.gentoo.releng/429/ - well this upgrade path is _very_ broken, should never have happened. Masking of core toolchain packages in profiles resulting in forced glibc downgrade should never ever be done. :=(
I don't think this is a ppc32 problem, just a ppc32 ul on ppc64. I'm reassigning to ppc64. :)
this reminds me, i need to add a check to the glibc ebuild to prevent users from downgrading their glibc
(In reply to comment #6)
> this reminds me, i need to add a check to the glibc ebuild to prevent users
> from downgrading their glibc
Agreed. However, the bug is not that this downgrading is impossible, but also that the evolution of stability of glibc-2.4 and the evolution of the 32ul ppc64 profile have forced some users into this impossible downgrade, with no clean way out.
That's why I reopen the bug, waiting for a fix allowing a glibc upgrade.
you seem to think there is supposed to be a way to downgrade
in your own low message you showed why it cant happen:
version `GLIBC_2.4' not found (required by /usr/lib/libsandbox.so)
that means sandbox was built against glibc-2.4 and it *cannot* work against anything older than that ... sandbox isnt the only thing that'd be broken
in other words, it's never going to happen
come up with real fixes for the real bugs, stop trying to invent wrong solutions for things that arent bugs
Following an offline email exchange with SpanKY, I changed the title of the bug (avoiding the confusion on my intention to downgrade glibc).
The workaround to override the profile (tahnks SpanKY !) is to create the file /etc/portage/profile/packages with the following lines
I close this bug, since it was caused by a transient change of the profiles, and a workaround has been found ( comment #9)