RE: [gentoo-user] changing CHOST

[Timothy A. Holmes]

-----Original Message-----
From: richard.j.fish@×××××.com on behalf of Richard Fish
Sent: Sun 9/10/2006 2:30 PM
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] changing CHOST
 
On 9/10/06, Timothy A. Holmes <tholmes@×××××××××.net> wrote:
> Richard:
>
> I got this one - thanks, the problem is that im getting conflicting
> advice from multiple sources.

I think the problem with this is (and I don't mean to offend when I
say this...) that the people who would be able to figure out how to
successfully change CHOST on a live system have never have to do so,
because they set it right from the start.

So my advice is based on:

http://article.gmane.org/gmane.linux.gentoo.user/169260

As well as forums threads such as:

http://forums.gentoo.org/viewtopic-t-386633.html

(BTW, one has to be a bit careful on the forums, as some of those
threads have answers from people who recommend merging system and
world twice each....which is pretty much useless.)

> You cant do that no matter what

Pretty sure this isn't true.  But it would be wrong to suggest that it
is an easy thing to change, or say that there is some method that
guarantees you won't end up booting from your live CD to repair
things.

> To
> You don't want to do that

This one seems entirely up to you.  At this point in Gentoo, you
either have to change CHOST, or add ">=sys-libs/glibc-2.4" to
/etc/portage/package.mask, since 2.4 is nptl only, and that requires
better than i386.

> To
> It wont do any good

If this was the entire answer, it is simply clueless.  Using the CHOST
that matches your processor lets gcc use more effecient instructions
for newer processors.  This is what makes nptl so more efficient than
linuxthreads, because it uses processor instructions specifically
designed for multi-CPU synchronization.

Now whether the improvements are worthwhile or not is a subjective
thing, and one could argue that it isn't worth the effort.  This goes
back to the previous point.

> To
> Bootstrap wont run

Sounds like a bug.

> To
> No need for bootstrap, just change and do the emerges

Well I would have thought so too, but that hasn't worked for some
people.  Again, there is no definitive guide on changing CHOST.  The
safest option is to boot from a livecd and re-install using the new
CHOST.

But if you are willing to go that far anyway, it can't hurt to try the
bootstrap.sh ; emerge -e system ; emerge -e world sequence.
Basically, if you make it through the emerge -e system part, you have
a sane base system and anything else that breaks indicates a problem
with the change in profile or gcc versions, not the change in CHOST.

BTW, Darren's answer on this thread seems incorrect to me.  Changing
CHOST is a pretty significant thing to tweak, certainly as significant
as changing gcc versions, and you really should re-merge *everything*
to make sure your something doesn't wind up broken.

> Im a bit confused to be honest

That's ok.  It isn't an easy question to answer unfortunately.

-Richard
-- 
gentoo-user@g.o mailing list


Richard:

thanks a great deal for your answer -- it is extremely helpful.

I think i will give it a shot, the system in question right now is only my rsync mirror -- it as additional tasks planned to be installed, but that hasn't happened yet.  if i can get it to run, then it is cool, but if not, i havent lost a great deal.  I do however have a couple other production boxes that I REALLY dont want to have to rebuild that might (i havent checked yet) be built using the same stage 3 -- they are running ok, speeds and processor loads look ok, so if this breaks this box, im not going to attempt it on the other ones.

I'll let you know how it goes

TIM