public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Meino Christian Cramer <Meino.Cramer@gmx.de>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] /etc/make.conf: changing CHOST on same system
Date: Mon, 04 Sep 2006 05:24:05 +0200 (CEST)	[thread overview]
Message-ID: <20060904.052405.74752259.Meino.Cramer@gmx.de> (raw)
In-Reply-To: <200609021130.59257.bo.andresen@zlin.dk>

From: Bo Ørsted Andresen <bo.andresen@zlin.dk>
Subject: Re: [gentoo-user] /etc/make.conf: changing CHOST on same system
Date: Sat, 2 Sep 2006 11:30:55 +0200

> On Saturday 02 September 2006 10:58, Meino Christian Cramer wrote:
> > So, is it correct / necessary in my case to do the following for
> >  upgrading to gcc-4.1:
> >
> >  Correct the CHOST fault
> >  emerge -e world
> >  emerge glibc
> >  emerge -e world
> >  emerge gcc
> >  emerge -e world
> 
> ...?.
> 
> I guess you didn't follow this list too carefully the last couple of days... 
> Anyway, no you shouldn't emerge -e world more than once!
> 
> 1. Correct the CHOST in make.conf
> 2. Make sure the nptl and nptlonly use flags are enabled.
> 3. *If* you want to upgrade your profile in the near future this may be a good 
> time to do so. This step is optional. You may have a look at [1] for more 
> info about this.
> 4. Follow the gcc upgrade guide [2].
> 
> Following the gcc upgrade guide will upgrade glibc and pretty much everething 
> else that isn't quite up to date during the emerge -e world. Make sure that 
> you follow the "General Upgrade Instructions" carefully though.
> 
> [1] http://www.gentoo.org/doc/en/gentoo-upgrading.xml
> [2] http://www.gentoo.org/doc/en/gcc-upgrading.xml
> -- 
> Bo Andresen

Hi Bo !

 ...unfortunately I got stuck again.

 What I did:
 Changed CHOST from i386* i686*, ensure that nptl and nptlonly are USEd.
 (I am running an AMD Athlon(tm) 64 X2 Dual Core Processor 3800+)

 emerge -uav gcc

 The result was:
 The first package (it was not the gcc), what was tried to compile, failed with
 "Compiler cannot create output" (or similiar, dont remember
 exactly...)

 Looks like, as the new CHOST results in looking for 
 /usr/lib/gcc/i686-pc-linux-gnu (which is not existing) instead of 
 /usr/lib/gcc/i386-pc-linux-gnu (which still does exist).

 Ok, but when I reset CHOST to i386* again, the new glibc will fail to
 compile, since it insist of haveing a CPU better then i386* (which
 was the inital reason for posting my problems.)

 Do I have a "recursive Armageddon" here ?

 Since I will replace gcc, would it be a soultion to rename all
 occurences of i386-pc-linux-gnu in my root directory tree with
 i686-pc-linux-gnu ??? Or symlink it? Or do I shoot myself just in my
 other foot this way?
 I know that this "solution" would be not gentleman like but a hack of a
 rookie...but...when gentlemen does not succeed ??? ;)

 By the way:
 I looked for sane CFLAGS for my CPU by best performance.
 I am not sure for the -msse3 flag...
 The docs say: You can enable -msse3 for the CPU (mentioned above)
 when the "pni" entry is in /proc/cpuinfo (which is in my case). On
 the other side /proc/cpuinfo mentioned sse and sse2 but not sse3:
 
   processor       : 0
   vendor_id       : AuthenticAMD
   cpu family      : 15
   model           : 43
   model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
   stepping        : 1
   cpu MHz         : 2002.999
   cache size      : 512 KB
   physical id     : 0
   siblings        : 2
   core id         : 0
   cpu cores       : 2
   fdiv_bug        : no
   hlt_bug         : no
   f00f_bug        : no
   coma_bug        : no
   fpu             : yes
   fpu_exception   : yes
   cpuid level     : 1
   wp              : yes
   flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
           cmov pat pse36 clflush mmx fxsr #sse# #sse2# ht syscall nx
           mmxext fxsr_opt lm 3dnowext 3dnow #pni# lahf_lm cmp_legacy ts
           fid vid ttp
   bogomips        : 4012.21
 
 Same goes for processor 1, but with slightly different bogomips
 (Sometimes even identical things seems to be different... ;O) .

 I dont know, how to get the information, whether my CPU has a
 Winchester, Manchester, Venice or whatever die...

 Last thing:
 When the gentoo docs talk about "AMD64" without mentioning, whether
 it is meant a 32bit- or 64bit-system....is it valid for 32bit AND
 64bit or only 64bit or...
 Sometimes I am not sure whether the docs are talking about "my
 system" since I am running a AMD64 -- a 64bit CPU -- in 32bit mode.


 Thanks a lot in advance for any help out of my homebrewed disaster...
 Keep hacking!
 mcc

-- 
gentoo-user@gentoo.org mailing list



      reply	other threads:[~2006-09-04  3:32 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-02  4:42 [gentoo-user] /etc/make.conf: changing CHOST on same system Meino Christian Cramer
2006-09-02  5:38 ` Richard Fish
2006-09-02  8:58   ` Meino Christian Cramer
2006-09-02  9:30     ` Bo Ørsted Andresen
2006-09-04  3:24       ` Meino Christian Cramer [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060904.052405.74752259.Meino.Cramer@gmx.de \
    --to=meino.cramer@gmx.de \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox