Weird CHOST settings causing compile mixup - Changing CHOST

[amne]

sinanqapudan: Thanks for the feedback, good to hear it works.

[mirojira]

mirojira: Thanks for your feedback even though that method is deprecated now.
You may want to check your /etc/env.d for files that don't belong there any more as described in the new guide, too.

I switched from i386 to i686 and after emerge -e world i removed old versions of gcc. Everything seems to be OK. I checked /etc/env.d following your howto and I have

Code: Select all

localhost gcc # grep 586 /etc/env.d/
localhost gcc # grep 386 /etc/env.d/
localhost gcc # 

But

Code: Select all

localhost gcc # ls -la
total 16
drwxr-xr-x 2 root root   80 Sep  5 15:22 .
drwxr-xr-x 4 root root 4096 Sep  4 18:50 ..
-rw-r--r-- 1 root root   32 Sep  4 01:29 config
-rw-r--r-- 1 root root   32 Sep  3 18:14 config-i686-pc-linux-gnu
-rw-r--r-- 1 root root  292 Sep  4 01:29 i686-pc-linux-gnu-4.1.1

Code: Select all

localhost gcc # cat config-i686-pc-linux-gnu
CURRENT=i386-pc-linux-gnu-3.3.6

Is it OK? Or should I remove config-i686-pc-linux-gnu?
I did not run

Code: Select all

# env-update && source /etc/profile

Sould I run it?

[amne]

Code: Select all

localhost gcc # cat config-i686-pc-linux-gnu
CURRENT=i386-pc-linux-gnu-3.3.6

Is it OK? Or should I remove config-i686-pc-linux-gnu?

Yeah, that one can be deleted.

I did not run

Code: Select all

# env-update && source /etc/profile

Sould I run it?

env-update just recreates the files in /etc/env.d/ (by looking in the subdirs gcc and binutils among other stuff), so it can never be wrong to do that.
source /etc/profile is only needed if you update the stuff in /etc/env.d and continue working in the same shell (e.g. to rebuild world). Nothing wrong with doing that as often as you want either.

[wilson]

I had the same problem as another poster that glibc-2.4-r3 wouldnt compile, which was due to the wrong version of gcc being used. Anyway its all fixed now.

Thanks for writing this guide, its saved me from recompiling the same thing 4 times which others have suggested

I also had to re-emerge "groff", as I had lib failures when using man pages. I hope others will add to the list of packages that need an re-emerge.

[polemoser]

Thanks for the mini-howto, which i followed.

On my Pentium 3, emerge -e world has now taken almost 4 days and has still not finished...

If you have installed courier / courier-imap - series, I'd highly recommend to recompie all these packages, including courierauth. Otherwise your won't be able to use any courier services because login will fail.

I experienced the lib failures as well with the manpages ( as wilson already mentioned );

In the CFLAGS in /etc/make.conf I have the flag -mcpu=i686 set. Now the compiler always yelles

Code: Select all

'-mcpu=' is deprecated. Use '-mtune=' or '-march=' instead.

In my opinion, the right decision is to take "-march=pentium3", because of:

Code: Select all

tux ~ $ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 8
model name      : Pentium III (Coppermine)
stepping        : 3
cpu MHz         : 733.468
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse
bogomips        : 1470.26

But if I change this from "-mcpu=i686" to "-march=pentium3": Will this have any unforseen sideffects? Will this brake anything? Thanks for your help.

[amne]

If you have installed courier / courier-imap - series, I'd highly recommend to recompie all these packages, including courierauth. Otherwise your won't be able to use any courier services because login will fail.

Thanks, will add that as soon i have a working environment again (got some hardware issues currently), as well as groff (thanks wilson).

But if I change this from "-mcpu=i686" to "-march=pentium3": Will this have any unforseen sideffects? Will this brake anything? Thanks for your help.

From man gcc:

-mcpu=cpu-type
A deprecated synonym for -mtune.

If you want the same behaviour as before, use -mcpu=i686, which builds binaries for i686 that can also be run on other cpus (but are optimized for i686).
If you use -march instead, the code will only run on the platform specified (and higher, e.g. pentium 4), so -march=i686 code would not run on an i586 cpu, but still on an athlon. If you use -march=pentium3, it also wouldn't run on an athlon (but still on a pentium 4).

[richfish]

amne,

Thanks very much for creating the guide. A couple of quick items:

1. Since the most common change will probably be i386 to i686, is it sensible to do a global search-replace of i686 with i386, and i586 with i686? That way most users following the guide should not need to do any translation and we might help them avoid mistakes. Particularly in the fixing up of env.d.

2. The "may want to run emerge -e world" part at the end feels risky to me. Just from the way it is worded, my guess is that quite a few users will try it without emerge -e world, and /then/ we'll find out their systems are broke. Does it make sense to strongly suggest at least an "emerge -e system", as everything else should be fixable if that works?

[G F0rce 1]

Okay, I'm done following the guide and everyrhing seems to work just fine, the only package failed was iptraf. Everything seems to be fine. Is there definitive way to test if I've done everything the right way? And is it really not nessecary to do a emerge -e system? Or is that included with the emerge -e world ?

[richfish]

Emerge -e world will rebuild system packages as well, so if that completed successfully, everything should be working for your system. I was suggesting emerge -e system as the alternative for those who don't emerge -e world.

[amne]

1. Since the most common change will probably be i386 to i686, is it sensible to do a global search-replace of i686 with i386, and i586 with i686? That way most users following the guide should not need to do any translation and we might help them avoid mistakes. Particularly in the fixing up of env.d.

When i wrote the doc, i wanted to keep as much as possible to the real life test i've been running (which was i686 to i586), but i think it's a good idea to change it.

2. The "may want to run emerge -e world" part at the end feels risky to me. Just from the way it is worded, my guess is that quite a few users will try it without emerge -e world, and /then/ we'll find out their systems are broke. Does it make sense to strongly suggest at least an "emerge -e system", as everything else should be fixable if that works?

It's intentionally worded like that, as it really shouldn't be necessary to do it. If you want to be 100% safe, you may want to do it, in general recompiling the packages mentioned in the guide (need to add those mentioned here recently yet) should really be enough. There's also some discussion about it in [bug]147502[/bug], see comment 3 and 4.

[amne]

JFYI, i've updated the guide and added some more packages that need to be rebuilt. It also explains how to migrate from i386 to i686 by default now as this is probably the most common task.

[wilson]

Better add telnet as well:

telnet: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory

oh also add mysql!
and nmap

[amne]

Those errors seem to happen when upgrading from gcc 3.3, which introduces some abi changes that require you to rebuild packages - so it is not a CHOST issue. Maybe the folks who had problems with groff etc can confirm that?
If you upgrade from gcc 3.3, please take a look at the gcc upgrade guide as well.

[wilson]

The system had the latest 3.x gcc emerged, but I never changed the compiler via gcc-config (this is a new command for me!) So I will assume it was a 3.3 compiler

[amne]

Update: Added a warning not to upgrade gcc at the same time as this can cause problems.

[T-O7]

Hello,
I followed the guide to migrate from i386 to i686. When upgrading my kernel though, I see several references to i386 when the kernel is compiling:

Code: Select all

SYMLINK include/asm -> include/asm-i386
scripts/kconfig/conf -s arch/i386/Kconfig

  CC      arch/i386/kernel/process.o
  CC      arch/i386/kernel/semaphore.o
  CC      arch/i386/kernel/signal.o
  AS      arch/i386/kernel/entry.o
  CC      arch/i386/kernel/traps.o
  etc...

Is there any way to correct this? Did I miss a step?

[desultory]

I followed the guide to migrate from i386 to i686. When upgrading my kernel though, I see several references to i386 when the kernel is compiling:

Code: Select all

SYMLINK include/asm -> include/asm-i386
scripts/kconfig/conf -s arch/i386/Kconfig

  CC      arch/i386/kernel/process.o
  CC      arch/i386/kernel/semaphore.o
  CC      arch/i386/kernel/signal.o
  AS      arch/i386/kernel/entry.o
  CC      arch/i386/kernel/traps.o
  etc...

What is being indicated there is that the kernel being built is to be a 32 bit PC compatible executable, not that it is optimized specifically for a 386 processor. The source code in arch/i386 is used for processors ranging from Intel 80386 types through current 32 bit (and 64 bit used as 32 bit) PC compatible processors, the output quoted is to be expected when building a kernel to be used with such processors.

Is there any way to correct this?

Use a different processor type, which is unlikely to be the type of fix you were considering.

Did I miss a step?

While not in evidence here, it is also not excluded from possibility by the quoted output.

[cmcheung]

Thanks very much for this guide!

I have some questions though. I'm paranoid about going through some of the steps, in fear of screwing my system up, so I'm going to try to get confirmation here in regards to what to do. Here goes...

I have done emerge -av1 binutils gcc glibc, which seemed to work fine. When i do gcc-config -l however, I get the following results:

Code: Select all

localhost ~ # gcc-config -l
 [1] i386-pc-linux-gnu-3.3.6
 [2] i386-pc-linux-gnu-3.3.6-hardened
 [3] i386-pc-linux-gnu-3.3.6-hardenednopie
 [4] i386-pc-linux-gnu-3.3.6-hardenednopiessp
 [5] i386-pc-linux-gnu-3.3.6-hardenednossp
 [6] i386-pc-linux-gnu-3.4.6
 [7] i386-pc-linux-gnu-3.4.6-hardened
 [8] i386-pc-linux-gnu-3.4.6-hardenednopie
 [9] i386-pc-linux-gnu-3.4.6-hardenednopiessp
 [10] i386-pc-linux-gnu-3.4.6-hardenednossp
 [11] i686-pc-linux-gnu-4.1.1 *

gcc-config -c, and both the binutils-config give the results listed on the how-to.

Next, when I grep 386 *, i get the following results:

Code: Select all

localhost env.d # grep 386 *
20java:LDPATH="/opt/blackdown-jdk-1.4.2.03/jre/lib/i386/:
/opt/blackdown-jdk-1.4.2.03/jre/lib/i386/native_threads/:
/opt/blackdown-jdk-1.4.2.03/jre/lib/i386/client/:
/opt/blackdown-jdk-1.4.2.03/jre/lib/i386/server/"

grep 686 * seems to give me what I want.

My question is if I can just go nuts and rm everything with i368-pc-linux*? Also, what should I do about the blackdown-jdk, in relation to i368?

Thanks for the help.

mod edit: added some line breaks to the code block
amne

[amne]

I have done emerge -av1 binutils gcc glibc, which seemed to work fine. When i do gcc-config -l however, I get the following results:

Code: Select all

localhost ~ # gcc-config -l
 [1] i386-pc-linux-gnu-3.3.6
 [2] i386-pc-linux-gnu-3.3.6-hardened
 [3] i386-pc-linux-gnu-3.3.6-hardenednopie
 [4] i386-pc-linux-gnu-3.3.6-hardenednopiessp
 [5] i386-pc-linux-gnu-3.3.6-hardenednossp
 [6] i386-pc-linux-gnu-3.4.6
 [7] i386-pc-linux-gnu-3.4.6-hardened
 [8] i386-pc-linux-gnu-3.4.6-hardenednopie
 [9] i386-pc-linux-gnu-3.4.6-hardenednopiessp
 [10] i386-pc-linux-gnu-3.4.6-hardenednossp
 [11] i686-pc-linux-gnu-4.1.1 *

i386-*-3.4.6 is your old gcc is your old gcc version, the output is fine if you haven't removed it from your system yet.
Also take a look at the gcc upgrading howto for instructions on gcc updates. Once you're done with it and unmerged the old gcc, it should be gone.

Code: Select all

localhost env.d # grep 386 *
20java:LDPATH="/opt/blackdown-jdk-1.4.2.03/jre/lib/i386/:
/opt/blackdown-jdk-1.4.2.03/jre/lib/i386/native_threads/:
/opt/blackdown-jdk-1.4.2.03/jre/lib/i386/client/:
/opt/blackdown-jdk-1.4.2.03/jre/lib/i386/server/"

Seems blackdown always uses i386 in the path whatever your CHOST is, so you can just leave that alone.

[ulor]

In order to make this useful changing from CHOST=i386 to CHOST=i686 remember to update your make.profile so that it is no longer pointing to no-nptl.

http://www.gentoo.org/doc/en/gentoo-upgrading.xml

Bri

[ulor]

A good place to find a very sweet script for doing a emerge -e world

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

Bri

[s0medude]

Hi all,

I used the guide to switch from i386 to 1686 but found my emerge -e world breaking repeatedly on dev-python/sip-4.2.1.
After some digging I found a Makefile for sip in /var/tmp/portage that still contained a reference to i386 . After deleting all packages from /var/tmp/portage everything compiled flawlessly.

Perhaps, and I am by no means a Gentoo Elite so please disregard this if the problem was caused by my own stupidity, an extra step could be added to the guide to make sure everything in /tmp/portage is removed before starting the emerge -e world.

HTH and thanks for the great guide guys,

Bravo_Kernel.

[amne]

After some digging I found a Makefile for sip in /var/tmp/portage that still contained a reference to i386 . After deleting all packages from /var/tmp/portage everything compiled flawlessly.

Strange, portage usually cleans up there before compiling so old Makefiles should be wiped as well. Do you have FEATURES="keepwork" enabled in your make.conf by chance?

[s0medude]

Hi Amne,

Thanks for your fast reply. I just checked and there is no 'keepwork' anywhere in my make.conf so IMHO this could be a unusual hickup of Portage on my system or something structural but very rare (a bug).

Anyway, it is reported now so anybody experiencing the same thing should be able to fix it.

HTH,

Bravo_Kernel

[wrs4]

I have a dual-Xeon 2GHz that had CHOST=i386. I updated to i686, with gcc updates from 3.x to 4.1.1.

When I got to the emerge -e world step in the guide, emerge died on gmp. When I looked at the log, it said it couldn't find a c++ compiler. The config log showed that it had the right g++, and g++ --version confirmed it. After beating my head on the wall for a few minutes looking at log and config files (and finding nothing useful), I decided to re-emerge gcc and glibc, then rerun emerge -e world. That did the trick. Just a (hopefully useful) tip.