Kyle Liddell posted <[EMAIL PROTECTED]>, excerpted below,
on Sun, 10 Apr 2005 18:00:30 -0500:
> I've
> finally gotten to code listing 8, emerge glibc after switching to the
> 2005.0 profile. I'm getting the "cannot compute sizeof (long double),
> 77" error. I've gone back up to the emerge emul-glibc-blah part and
> redone that, then started from there, same results. Gone and done that
> step immediately before copying the files from /emul/blah to
> {,usr}/lib32 and such. I've even tried switching to the 2005.0 profile,
> then doing the re-emerge of emul-blah and portage, but that refuses to
> do anything and states that I've improperly switched profiles
You've probably seen this, checked it, and just don't mention it
specifically, but it's worth asking, anyway...
You /did/ have a working USE=multilib installion on 2004.3, right? If
not, go back to 2004.3, remerge gcc, glibc, and portage (I believe they
have to be merged in a specific order, to get full multilib, but don't
recall which, tho I think you /do/ get an error if you get the order
wrong, so just try it and see), with USE=multilib, THEN try the switch to
2005.0.
If you had working multilib b4, I can't say, however, here's one thing
that caught me, that hasn't been brought up often, here. For some reason,
I had an incompletely unmerged old version of gcc-config laying around.
That is, I had the version that portage said was installed, with the
gcc-config executable in one location, but at some point they had switched
locations, and the old gcc-config executable was still hanging around in
the old location, for whatever reason.
What was happening is that the old version came first in the path, so when
it was simply called as "gcc-config", the old version would run. When it
was called by absolute path, of course, the new version would run.
However, the conflict of the old and new versions caused me to have an
inconsistent gcc configuration, and for some time, I was rather stumped at
my inability to progress in the 2005.0 upgrade, as a result. Once I
figured out the issue and manually killed the old gcc-config, then
remerged the new one again to straighten out my config, things worked
/much/ better.
I /did/ file a bug on this, suggesting that new gcc-config versions should
do a sanity check on the old location and ensure any old pieces laying
around were cleaned up, and that further, the calls to gcc-config from the
merge process of the package itself be standardized to always use the
absolute path, and I believe the newest gcc-config versions do just that.
However, I'm not positive they are out of ~amd64 yet (since I run a fully
~amd64 system), so the bug could conceivably still be around, if whatever
triggered my still having the old version around hit anyone else.
A quick way to check:
# which -a gcc-config
The -a causes it to report /all/ occurrences in the path, not just the
first one. If you get two results, you definitely have the problem I did.
One of them is old. Use equery files and/or equery belongs (or the
similar qpkg or whatever commands) to resolve which is the "right"
version, and delete the other one(s). Then remerge the current version,
and reset your gcc-config to something valid, and try the profile switch
process again.
However, I doubt this will be the issue for most. It's just a
possibility, one that nabbed me, here.
It'd also be interesting to see how many folks now having problems are on
~amd64, and how many on stable amd64, as well as how many had been running
USE=multilib for some time, vs. those that weren't and tried the upgrade
without it, vs. those that weren't, but changed that and remerged portage,
glibc, and gcc (at minimum) with 2004.3, before attempting anything
further on the 2005.0 upgrade.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html
--
[email protected] mailing list
