Weird CHOST settings causing compile mixup - Changing CHOST

[kilburna]

I cannot recall how this happened but I have upgraded to 4.1.1 GCC. This is a C3 system which is a 586. So my CHOST should be CHOST="i586-pc-linux-gnu". I am sure at one stage it was.

When I change it to CHOST="i586-pc-linux-gnu", packages make, gcc and glibc will fail. If I leave it as CHOST="i386-pc-linux-gnu" it will compile. In fact, I have to change it CHOST="i586-pc-linux-gnu" as glibc 2.4 will not compile on <i486.

My current make.conf

Code: Select all

CFLAGS="-march=i586 -m3dnow -Os -pipe -fomit-frame-pointer"
CHOST="i386-pc-linux-gnu"
CXXFLAGS="${CFLAGS}"

Current gcc-config -l

Code: Select all

[1] i386-pc-linux-gnu-3.4.6
[2] i386-pc-linux-gnu-3.4.6-hardened
[3] i386-pc-linux-gnu-3.4.6-hardenednopie
[4] i386-pc-linux-gnu-3.4.6-hardenednopiessp
[5] i386-pc-linux-gnu-3.4.6-hardenednossp
[6] i386-pc-linux-gnu-4.1.1 *

I would like to have a consistent make.conf for ALL packages. Does this mean that my GCC is i386 compiled? or should I just rebuild from scratch.

Code: Select all

CFLAGS="-march=i586 -m3dnow -Os -pipe -fomit-frame-pointer"
CHOST="i586-pc-linux-gnu"
CXXFLAGS="${CFLAGS}"

Any direction of how to solve this would be appreciated.

Made sticky and title changed by NeddySeagoon - with the release of 2006.1 there will be a lot of this

[NeddySeagoon]

kilburna,

Edit - Outdated overly cautious material removed - see amnes' guide and read further down the thread

[amne]

Actually i would not recommend bootstrapping. Changing CHOST is subject of a lot of debates - and there are many different opinions floating around.

edit:
removed some obsolete stuff as i am currently working on a little howto - see my post below for a link.

[psic]

It would be great to get some feedback if that method actually works as i don't know from personal experience.

I'm currently asking some other folks for input on this, so if you want more answers to confuse you, perhaps you may want to wait a while before starting.

Well, I'm trying this now, so I'll post back with the results, though I have no idea when that might be. Besides this, I've been following the gcc-4.1 thread and I just have to say Thanks amne! Your posts have so far helped me immeasurably

/me ows you a beer.

EDIT: well well, Graz, seems like you're not that far away, hehe

[mirojira]

I am trying to do what amne recommended

# emerge --oneshot --emptytree glibc binutils gcc

and

>>> Emerging (21 of 21) sys-libs/glibc-2.4-r3 to /
.
.
.
configure: error:
*** These critical programs are missing or too old: gcc
*** Check the INSTALL file for required versions.

!!! ERROR: sys-libs/glibc-2.4-r3 failed.
Call stack:
ebuild.sh, line 1539: Called dyn_compile
ebuild.sh, line 939: Called src_compile
glibc-2.4-r3.ebuild, line 1179: Called toolchain-glibc_src_compile
glibc-2.4-r3.ebuild, line 251: Called glibc_do_configure 'nptl'
glibc-2.4-r3.ebuild, line 941: Called die

!!! failed to configure glibc
!!! If you need support, post the topmost build error, and the call stack if relevant.

What to do now?

[mirojira]

I found the solution in http://forums.gentoo.org/viewtopic-t-49 ... glibc.html.

For those who have never used gcc-config before: "gcc-config --list-profiles" displays a list of all GCC versions which are currently installed on your box. The compiler you are currently using is marked with an asterisk. In order to change this "current" compiler to a different one from the list, remember the number between the brackets on the left side of the line which contains the compiler version you want to use. Then use "gcc-config <number>" to change the system default compiler to the list entry <number>, where <number> is the the number you remembered in the previous step.

[G F0rce 1]

So, wich one of the methods is the best one? I need to change my CHOST because of a GCC upgrade that needs NTPL, wich won't work with my CHOST. So wich method should I use? Thanks in advance!

[amne]

If you can wait a few days, i'm currently putting together some instructions with the help from vapier, one of our toolchain devs. I am currently just testing them in a chroot and so far they seem to be working. As soon i'm finished, i'll post them here. Since they are definitely better than what i've posted before, i'd recommend waiting for them.

[G F0rce 1]

Thank you very much, in that case I will keep watching this topic!

[MdaG]

I also have to change my CHOST before upgrading to gcc 4.1. I've been suggested to use emwrap, but I haven't dared start yet. I'll just wait for Amne to post again

*edit*
The alternative for me seems to be to emerge system and world trice !!! (that's over 2000 packages)

[neysx]

I cannot recall how this happened but I have upgraded to 4.1.1 GCC. This is a C3 system which is a 586.

If you change your CHOST, you might as well switch to i686 which a C3 is.
See http://forums.gentoo.org/viewtopic-p-34 ... ml#3439979

Hth

[mirojira]

Code: Select all

# emerge --oneshot --emptytree glibc binutils gcc
# emerge --emptytree system
# emerge --emptytree world

It would be great to get some feedback if that method actually works as i don't know from personal experience.

Yesterday I finished. It took almost 24 hours. System emerged 99 packages and world 541.
Two packages failed during emerge -e world. I continued using emerge --resume --skipfirst.
After I have finished I recompiled this two packages. One of them media-libs/libmpeg3-1.5.2
fails repeatedly.
After reboot alsa, e100 and usblp modules had not worked. Recompilation of the kernel with new
version of GCC fixed the problem.
I would say that this method works without any essential problems.

[MdaG]

If you also are currently updating to gcc 4.1 and following the upgrade guide, it recommeds both emerge -e system and world. As i can only assume which impact changing gcc AND chost at the same will have, if you really want to be safe, try

Code: Select all

# emerge --oneshot --emptytree glibc binutils gcc
# emerge --emptytree system
# emerge --emptytree world

It would be great to get some feedback if that method actually works as i don't know from personal experience.

I'm currently asking some other folks for input on this, so if you want more answers to confuse you, perhaps you may want to wait a while before starting.

I'm getting confused as the posts above feel "general". I'm going to quote you now (since I need to change CHOST and upgrade gcc from 3.4 to 4.1) and ask:
Is all I need to do:
1) edit make.conf by changing CHOST
2) switch gcc to 4.1
3) emerge --oneshot -e glibc binutils gcc
4) emerge -e system
5) emerge -e world
6) emerge suspend2-sources

And I'm set?

[amne]

Here are the instructions i promised earlier in this thread:
http://dev.gentoo.org/~amne/temp/change-chost.txt

edit: It's now in the official docs: http://www.gentoo.org/doc/en/change-chost.xml

This is a beta version - i've tested it myself on a fresh install (well, actually just a chroot environment, but that shouldn't really make i difference), and it worked fine for me. Personally i'd recommend this method over all others as it takes care of the things actually causing trouble (see the part about cleaning up /etc/env.d), but please be aware this is still beta and let me know if there are errors or inconsistencies in it.
Currently it's only a text file, perhaps there'll be a nice to read version too.

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.

MdaG: I can't guarantee you 100% what's best, perhaps it makes sense to mask gcc 4.1 and the new glibc before changing, following my CHOST howto (and this rebuilding the old versions of the toolchain). Once you're done, you could unmask glibc 2.4 and gcc 4.1 again and simply follow the gcc upgrade guide.
If you don't mask glibc and gcc for the CHOST change you should be able to save some compile time, but you'll need to be extra careful with mixing both guides, e.g. call gcc-config, fix_libtool_files.sh with the right parameters. I assume that should work, but then again it's never been tested before and may fail under certain circumstances, so it may be a bit more risky.
This is what i would assume works:

• Follow http://dev.gentoo.org/~amne/temp/change-chost.txt in general
• after emerge -av1 binutils gcc glibc do not only check your gcc-config, but also change to the new compiler:

  Code: Select all

  gcc-config <your new gcc>
  # source /etc/profile

• Include --oldarch when calling fix_libtool_files.sh as described in the chost guide, not without it as in the gcc guide.
• The end of the CHOST guide recommends emerge -e world, the gcc guide recommends system + world.
  You don't need -e world + system + world, but i'd highly recommend emerge -e system + world.

That way everything mentioned in the gcc upgrade guide should be taken care of and i think this should work, but since you're probably the first person to test it better keep a backup around. Let me know if it worked.

edit: New information: Don't do both things at a time as this can lead to unexpected problems.

[psic]

Well, I used what is now 'obsolete' (though it's not that different from your mini how-to) as you say in your post above and it seems to have worked well. I've gone through the emerge -e system as well as emerge -e world, then --sync and --update --deep world, followed by a kernel re-compile (or rather compile as it's a new version). Everything works except for the ati-drivers, which I expect will work once I've re-emerged them.

Thanks again for the help!

[sinanqapudan]

I followed the instructions in amne's mini howto and changed CHOST in the make.conf file to i586 and afterdwards emerged binutils gcc glibc with

Code: Select all

# emerge -av1 binutils gcc glibc

The system emerged successfully gcc glibc but got stuck with glibc, requesting to insert the "nptl nptlonly" USE flags in the make.conf file, which I did. While I was there I also changed CHOST to i686 as I found out that it should be OK for my CPU (Athlon tbird). Then I re-emerged binutils gcc glibc.

As before, the system got stuck when emerging glibc.

Now, if I try to emerge glibc this is what I get:

Code: Select all

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild     U ] sys-libs/glibc-2.4-r3 [2.3.6-r4] USE="nls nptl nptlonly* -
build -glibc-omitfp -hardened -profile" 0 kB

Total size of downloads: 0 kB

Would you like to merge these packages? [Yes/No] y
>>> Emerging (1 of 1) sys-libs/glibc-2.4-r3 to / checking ebuild 
>>> checksums ;-) checking auxfile checksums ;-) checking miscfile 
>>> checksums ;-) checking glibc-2.4.tar.bz2 ;-) checking 
>>> glibc-ports-2.4.tar.bz2 ;-) checking glibc-libidn-2.4.tar.bz2 ;-) 
>>> checking glibc-2.4-patches-1.17.tar.bz2 ;-) checking 
>>> glibc-linuxthreads-20060605.tar.bz2 ;-) checking 
>>> glibc-powerpc-cpu-addon-v0.01.tgz ;-) Unpacking source...

 * Checking gcc for __thread support ...                                  [ ok ]
 * Checking kernel version (>=2.6.9) ...                                  [ ok ]
 * Checking linux-headers version (>=2.6.9) ...                           [ ok ]

>>> Unpacking glibc-2.4.tar.bz2 to /var/tmp/portage/glibc-2.4-r3/work
>>> Unpacking glibc-linuxthreads-20060605.tar.bz2 to 
>>> /var/tmp/portage/glibc-
2.4-r3/work/glibc-2.4
>>> Unpacking glibc-libidn-2.4.tar.bz2 to /var/tmp/portage/glibc-2.4-
r3/work/glibc-2.4
>>> Unpacking glibc-ports-2.4.tar.bz2 to /var/tmp/portage/glibc-2.4-
r3/work/glibc-2.4
>>> Unpacking glibc-powerpc-cpu-addon-v0.01.tgz to 
>>> /var/tmp/portage/glibc-2.4-
r3/work/glibc-2.4
>>> Unpacking glibc-2.4-patches-1.17.tar.bz2 to 
>>> /var/tmp/portage/glibc-2.4-
r3/work
 * Applying Gentoo Glibc Patchset 2.4-1.17 ...
 *   0010_all_glibc-ssp-compat.patch ...                                  [ ok ]
 *   1030_all_glibc-manual-no-perl.patch ...                              [ ok ]
 *   1040_all_2.3.3-localedef-fix-trampoline.patch ...                    [ ok ]
 *   1050_all_glibc-cvs-nscd-system-headers.patch ...                     [ ok ]
 *   1060_all_glibc-cvs-getcwd-path-max.patch ...                         [ ok ]
 *   1090_all_glibc-2.3.6-fix-pr631.patch ...                             [ ok ]
 *   1100_all_glibc-2.3.3-china.patch ...                                 [ ok ]
 *   1130_all_glibc-2.4-undefine-__i686.patch ...                         [ ok ]
 *   1150_all_glibc-signed-printf-h.patch ...                             [ ok ]
 *   1530_all_glibc235-gcc34-m68k-seccomment.patch ...                    [ ok ]
 *   1540_all_hppa-drop-utimes.patch ...                                  [ ok ]
 *   1600_all_glibc-LD_POINTER_GUARD.patch ...                            [ ok ]
 *   3000_all_2.3.6-dl_execstack-PaX-support.patch ...                    [ ok ]
 *   3010_all_2.3.3_pre20040117-pt_pax.patch ...                          [ ok ]
 *   4000_all_2.3.4-hardened-sysdep-shared.patch ...                      [ ok ]
 *   4010_all_2.3.5-hardened-iconvconfig-unnest.patch ...                 [ ok ]
 *   5021_all_2.3.6-fnmatch.patch ...                                     [ ok ]
 *   5063_all_glibc-dont-build-timezone.patch ...                         [ ok ]
 *   5070_all_cross-compile-nptl.patch ...                                [ ok ]
 *   5100_all_no-aliases-if-unsigned.patch ...                            [ ok ]
 *   6001_all_alpha-glibc-2.4-xstat.patch ...                             [ ok ]
 *   6220_all_glibc-2.4-arm-cirrus-ep93xx-maverick-crunch-fpu.patch ...   [ ok ]
 *   6230_all_glibc-2.4-arm-eabi-syscall-updates.patch ...                [ ok ]
 *   6400_all_sh-glibc-2.3.2-fpscr_values.patch ...                       [ ok ]
 *   6605_all_glibc-2.4-fpu-cw-mips.patch ...                             [ ok ]
 *   6630_all_glibc-2.4-cvs-mips-multilib.patch ...                       [ ok ]
 *   6635_all_glibc-2.4-mips-nptl-fork.patch ...                          [ ok ]
 *   6650_all_glibc-2.4-mips-rlimit-typo.patch ...                        [ ok ]
 *   6660_all_glibc-mips-mman-updates.patch ...                           [ ok ]
 *   6670_all_glibc-mips-missing-libm-hidden-defs.patch ...               [ ok ]
 *   6680_all_glibc-mips-updates.patch ...                                [ ok ]
 *   6901_all_2.4-amd64-strings-20060609.patch ...                        [ ok ]
 *   6901_all_2.4-new-libm-20060321.patch ...                             [ ok ]
 *   6910_all_glibc-suse-hashvals.patch ...                               [ ok ]
 * Done with patching
 * Using GNU config files from /usr/share/libtool
 *   Updating scripts/config.sub                                          [ ok ]
 *   Updating scripts/config.guess                                        [ ok ]
>>> Source unpacked.
>>> Compiling source in /var/tmp/portage/glibc-2.4-r3/work/glibc-2.4 ...

 *             ABI:   default
 *          CBUILD:   i686-pc-linux-gnu
 *           CHOST:   i686-pc-linux-gnu
 *         CTARGET:   i686-pc-linux-gnu
 *      CBUILD_OPT:
 *     CTARGET_OPT:
 *              CC:
 *          CFLAGS:   -march=athlon-tbird -pipe -finline-limit=2000 -O2

 * Configuring GLIBC for nptl with:
                --disable-stackguard-randomization
                --enable-old-ssp-compat
                --with-tls
                --with-__thread
                --enable-add-ons=ports,nptl,c_stubs,libidn
                --enable-kernel=2.6.9
                --without-selinux
                --without-cvs
                --enable-bind-now
                --build=i686-pc-linux-gnu
                --host=i686-pc-linux-gnu
                --disable-profile
                --without-gd
                --with-headers=/usr/include
                --prefix=/usr
                --libdir=/usr/lib
                --mandir=/usr/share/man
                --infodir=/usr/share/info
                --libexecdir=/usr/lib/misc/glibc

checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking add-on ports for preconfigure fragments... am33 arm hppa m68k mips
configure: running configure fragment for add-on nptl
configure: running configure fragment for add-on c_stubs
configure: running configure fragment for add-on libidn checking sysdep dirs... sysdeps/i386/elf
nptl/sysdeps/unix/sysv/linux/i386/i686 nptl/sysdeps/unix/sysv/linux/i386
sysdeps/unix/sysv/linux/i386 ports/sysdeps/unix/sysv/linux nptl/sysdeps/unix/sysv/linux nptl/sysdeps/pthread sysdeps/pthread sysdeps/unix/sysv/linux sysdeps/gnu sysdeps/unix/common sysdeps/unix/mman sysdeps/unix/inet ports/sysdeps/unix/sysv/i386 sysdeps/unix/sysv/i386 ports/sysdeps/unix/sysv nptl/sysdeps/unix/sysv sysdeps/unix/sysv
sysdeps/unix/i386 ports/sysdeps/unix nptl/sysdeps/unix sysdeps/unix sysdeps/posix sysdeps/i386/i686/fpu nptl/sysdeps/i386/i686 sysdeps/i386/i686
sysdeps/i386/i486 nptl/sysdeps/i386/i486 sysdeps/i386/fpu nptl/sysdeps/i386
sysdeps/i386 sysdeps/wordsize-32 sysdeps/ieee754/ldbl-96 sysdeps/ieee754/dbl-64
sysdeps/ieee754/flt-32 sysdeps/ieee754 sysdeps/generic/elf sysdeps/generic checking for a BSD-compatible install... /bin/install -c checking whether ln -s works... yes checking for i686-pc-linux-gnu-gcc... gcc checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking how to run the C preprocessor... gcc -E checking for i686-pc-linux-gnu-g++... no checking for i686-pc-linux-gnu-c++... no checking for i686-pc-linux-gnu-gpp... no checking for i686-pc-linux-gnu-aCC... no checking for i686-pc-linux-gnu-CC... no checking for i686-pc-linux-gnu-cxx... no checking for i686-pc-linux-gnu-cc++... no checking for i686-pc-linux-gnu-cl... no checking for i686-pc-linux-gnu-FCC... no checking for i686-pc-linux-gnu-KCC... no checking for i686-pc-linux-gnu-RCC... no checking for i686-pc-linux-gnu-xlC_r... no checking for i686-pc-linux-gnu-xlC... no checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking for i686-pc-linux-gnu-ranlib... i686-pc-linux-gnu-ranlib checking whether as is GNU as... yes checking whether ld is GNU ld... yes checking for as... as checking version of as... 2.16.1, ok checking for ld... ld checking version of ld... 2.16.1, ok checking for pwd... /bin/pwd checking for i686-pc-linux-gnu-gcc... (cached) gcc checking version of gcc... 3.3.6, bad checking for gnumake... no checking for gmake... gmake checking version of gmake... 3.80, ok checking for gnumsgfmt... no checking for gmsgfmt... gmsgfmt checking version of gmsgfmt... 0.14.5, ok checking for makeinfo... makeinfo checking version of makeinfo... 4.8, ok checking for sed... sed checking version of sed... 4.1.4, ok checking for autoconf... autoconf checking whether autoconf works... yes
configure: error:
*** These critical programs are missing or too old: gcc
*** Check the INSTALL file for required versions.

!!! ERROR: sys-libs/glibc-2.4-r3 failed.
Call stack:
  ebuild.sh, line 1539:   Called dyn_compile
  ebuild.sh, line 939:   Called src_compile
  glibc-2.4-r3.ebuild, line 1179:   Called toolchain-glibc_src_compile
  glibc-2.4-r3.ebuild, line 251:   Called glibc_do_configure 'nptl'
  glibc-2.4-r3.ebuild, line 941:   Called die

!!! failed to configure glibc
!!! If you need support, post the topmost build error, and the call stack if relevant.

When checking the output of gcc-config and binutils-config I get

Code: Select all

tux ~ # 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

Code: Select all

tux ~ # gcc-config -c
 * gcc-config: No gcc profile is active!

Code: Select all

tux ~ # binutils-config -l
 [1] i686-pc-linux-gnu-2.16.1 *

Code: Select all

tux ~ # binutils-config -c
i686-pc-linux-gnu-2.16.1

Any idea on how to proceed from here?

Thanks a lot

[amne]

I assume you're switching from i386 to i686, right?
It seems that's the reason why gcc-config is already a bit confused once emerge stops due to ntpl(only) missing.
I would suggest you just skip compiling glibc for now, continue fixing your /etc/env.d, and call gcc-config as described (gcc-config i686-pc-linux-gnu-4.1.1 in your case then) and try to merge glibc before the emerge -e stuff (you may be able to skip that step as you're going to emerge -e then anyway, but at on the other hand you'd be able to see if it your environment is sane rather than some time when going through emerge -e). Hope that works.

[sinanqapudan]

Yes, I'm trying to switch from i386 to i686.

I'll try out your suggestions this evening and let you know what the results are.

Thanks a lot for the support.

Ciao

[G F0rce 1]

Here are the instructions i promised earlier in this thread:
http://dev.gentoo.org/~amne/temp/change-chost.txt

Thank you very much, I'm going to try the guide. I'll post some feed back as soon as I'm finished or a problem arises. Thanks again!

[sinanqapudan]

So this is what I get

Code: Select all

tux env.d # grep 686 *
05binutils:MANPATH=/usr/share/binutils-data/i686-pc-linux-gnu/2.16.1/man
05binutils:INFOPATH=/usr/share/binutils-data/i686-pc-linux-gnu/2.16.1/info
05binutils:LDPATH=/usr/i686-pc-linux-gnu/lib
tux env.d # grep 586 *
tux env.d # grep 386 *
05gcc:PATH="/usr/i386-pc-linux-gnu/gcc-bin/3.3.6"
05gcc:ROOTPATH="/usr/i386-pc-linux-gnu/gcc-bin/3.3.6"
05gcc:MANPATH="/usr/share/gcc-data/i386-pc-linux-gnu/3.3.6/man"
05gcc:INFOPATH="/usr/share/gcc-data/i386-pc-linux-gnu/3.3.6/info"
05gcc:LDPATH="/usr/lib/gcc-lib/i386-pc-linux-gnu/3.3.6:/usr/lib/gcc/i386-pc-linux-gnu/3.4.6:/usr/lib/gcc/i386-pc-linux-gnu/4.1.1"
05gcc-i586-pc-linux-gnu:PATH="/usr/i386-pc-linux-gnu/gcc-bin/3.3.6"
05gcc-i586-pc-linux-gnu:ROOTPATH="/usr/i386-pc-linux-gnu/gcc-bin/3.3.6"
05gcc-i686-pc-linux-gnu:PATH="/usr/i386-pc-linux-gnu/gcc-bin/3.3.6"
05gcc-i686-pc-linux-gnu:ROOTPATH="/usr/i386-pc-linux-gnu/gcc-bin/3.3.6"
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/"
tux env.d #

Now, I'm not so sure about what files I've got to remove from the system, because if I remove all 05gcc files referring to wrong CHOST (i386) then I will be left with no cc file at all.

Any suggestion?

Thanks

Edit: Added some spaces to the LDPATH line so it doesn't break the pagelayout. --Maedhros

[sinanqapudan]

OK, I try to follow the instructions, here's an account.

Step 1 - re-emerge binutils and gcc only:

Code: Select all

  
tux / # emerge -av1 binutils gcc

which yielded:

Code: Select all

>>> Original instance of package unmerged safely.
 * The current gcc config appears valid, so it will not be
 * automatically switched for you.  If you would like to
 * switch to the newly installed gcc version, do the
 * following:

 * gcc-config i686-pc-linux-gnu-4.1.1
 * source /etc/profile

 * Switching cross-compiler to i386-pc-linux-gnu-3.3.6 ...
>>> Regenerating /etc/ld.so.cache...                                      [ ok ]

 * If you intend to use the gcc from the new profile in an already
 * running shell, please remember to do:

 *   # source /etc/profile


 * If you have issues with packages unable to locate libstdc++.la,
 * then try running 'fix_libtool_files.sh' on the old gcc versions.

>>> Regenerating /etc/ld.so.cache...
>>> sys-devel/gcc-4.1.1 merged.

>>> No packages selected for removal by clean.

>>> Auto-cleaning packages...

>>> No outdated packages were found on your system.


 * Regenerating GNU info directory index...
 * Processed 174 info files.

Step 2 - check if some dead rats are still hanging around in /etc/env.d/ :

Code: Select all

tux ~ # cd /etc/env.d/
tux env.d # grep 686 *
05binutils:MANPATH=/usr/share/binutils-data/i686-pc-linux-gnu/2.16.1/man
05binutils:INFOPATH=/usr/share/binutils-data/i686-pc-linux-gnu/2.16.1/info
05binutils:LDPATH=/usr/i686-pc-linux-gnu/lib
tux env.d # grep 586 *
tux env.d # grep 386 *
05gcc:PATH="/usr/i386-pc-linux-gnu/gcc-bin/3.3.6"
05gcc:ROOTPATH="/usr/i386-pc-linux-gnu/gcc-bin/3.3.6"
05gcc:MANPATH="/usr/share/gcc-data/i386-pc-linux-gnu/3.3.6/man"
05gcc:INFOPATH="/usr/share/gcc-data/i386-pc-linux-gnu/3.3.6/info"
05gcc:LDPATH="/usr/lib/gcc-lib/i386-pc-linux-gnu/3.3.6:/usr/lib/gcc/i386-pc-linux-gnu/3.4.6:/usr/lib/gcc/i386-pc-linux-gnu/4.1.1"
05gcc-i586-pc-linux-gnu:PATH="/usr/i386-pc-linux-gnu/gcc-bin/3.3.6"
05gcc-i586-pc-linux-gnu:ROOTPATH="/usr/i386-pc-linux-gnu/gcc-bin/3.3.6"
05gcc-i686-pc-linux-gnu:PATH="/usr/i386-pc-linux-gnu/gcc-bin/3.3.6"
05gcc-i686-pc-linux-gnu:ROOTPATH="/usr/i386-pc-linux-gnu/gcc-bin/3.3.6"
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/"

Step 3 - do as emerge suggested in Setp 1:

Code: Select all

tux env.d # gcc-config i686-pc-linux-gnu-4.1.1

which yielded:

Code: Select all

 * Switching native-compiler to i686-pc-linux-gnu-4.1.1 ...
>>> Regenerating /etc/ld.so.cache...                                      [ ok ]

 * If you intend to use the gcc from the new profile in an already
 * running shell, please remember to do:

 *   # source /etc/profile

Step 4 - follow the above piece of advice:

Code: Select all

tux env.d # source /etc/profile

Step 5 - redo Step 2 (checking for dead rats):

Code: Select all

tux env.d # grep 686 *
05binutils:MANPATH=/usr/share/binutils-data/i686-pc-linux-gnu/2.16.1/man
05binutils:INFOPATH=/usr/share/binutils-data/i686-pc-linux-gnu/2.16.1/info
05binutils:LDPATH=/usr/i686-pc-linux-gnu/lib
05gcc:PATH="/usr/i686-pc-linux-gnu/gcc-bin/4.1.1"
05gcc:ROOTPATH="/usr/i686-pc-linux-gnu/gcc-bin/4.1.1"
05gcc:MANPATH="/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/man"
05gcc:INFOPATH="/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/info"
05gcc:LDPATH="/usr/lib/gcc/i686-pc-linux-gnu/4.1.1"
tux env.d # grep 386 *
05gcc-i586-pc-linux-gnu:PATH="/usr/i386-pc-linux-gnu/gcc-bin/3.3.6"
05gcc-i586-pc-linux-gnu:ROOTPATH="/usr/i386-pc-linux-gnu/gcc-bin/3.3.6"
05gcc-i686-pc-linux-gnu:PATH="/usr/i386-pc-linux-gnu/gcc-bin/3.3.6"
05gcc-i686-pc-linux-gnu:ROOTPATH="/usr/i386-pc-linux-gnu/gcc-bin/3.3.6"
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/"

Ah, the situation starts looking encouragingly like that described in amne's mini howto, so I resume from there.

Step 6 - remove the dead rats:

Code: Select all

tux env.d # rm 05gcc-i586-pc-linux-gnu
tux env.d # rm 05gcc-i686-pc-linux-gnu

Step 7 - checking binutils:

Code: Select all

tux env.d # cd binutils
tux binutils # ls -la
total 9
drwxr-xr-x 2 root root  128 Sep  6 21:22 .
drwxr-xr-x 5 root root 1120 Sep  6 23:16 ..
-rw-r--r-- 1 root root   15 Sep  6 21:22 config-i686-pc-linux-gnu
-rw-r--r-- 1 root root  126 Sep  6 21:22 i686-pc-linux-gnu-2.16.1
tux binutils # cat config-i686-pc-linux-gnu
CURRENT=2.16.1
tux binutils # cat i686-pc-linux-gnu-2.16.1
TARGET="i686-pc-linux-gnu"
VER="2.16.1"
LIBPATH="/usr/lib/binutils/i686-pc-linux-gnu/2.16.1"
FAKE_TARGETS="i686-pc-linux-gnu"

OK, everything as per the mini howto

Step 8 - check gcc:

Code: Select all

tux binutils # cd /etc/env.d/gcc
tux gcc # ls -la
total 58
drwxr-xr-x 2 root root  704 Sep  6 22:45 .
drwxr-xr-x 5 root root 1120 Sep  6 23:16 ..
-rw-r--r-- 1 root root   32 Sep  6 22:50 config
-rw-r--r-- 1 root root   32 Sep  6 00:18 config-i586-pc-linux-gnu
-rw-r--r-- 1 root root   32 Sep  6 22:45 config-i686-pc-linux-gnu
-rw-r--r-- 1 root root  296 Sep  6  2005 i386-pc-linux-gnu-3.3.6
-rw-r--r-- 1 root root  364 Sep  6  2005 i386-pc-linux-gnu-3.3.6-hardened
-rw-r--r-- 1 root root  369 Sep  6  2005 i386-pc-linux-gnu-3.3.6-hardenednopie
-rw-r--r-- 1 root root  372 Sep  6  2005 i386-pc-linux-gnu-3.3.6-hardenednopiessp
-rw-r--r-- 1 root root  369 Sep  6  2005 i386-pc-linux-gnu-3.3.6-hardenednossp
-rw-r--r-- 1 root root  292 Aug 29 22:43 i386-pc-linux-gnu-3.4.6
-rw-r--r-- 1 root root  356 Aug 29 22:43 i386-pc-linux-gnu-3.4.6-hardened
-rw-r--r-- 1 root root  361 Aug 29 22:43 i386-pc-linux-gnu-3.4.6-hardenednopie
-rw-r--r-- 1 root root  364 Aug 29 22:43 i386-pc-linux-gnu-3.4.6-hardenednopiessp
-rw-r--r-- 1 root root  361 Aug 29 22:43 i386-pc-linux-gnu-3.4.6-hardenednossp
-rw-r--r-- 1 root root  292 Sep  6 22:45 i686-pc-linux-gnu-4.1.1

Mmmm doesn't look good....

Step 9 - check config files:

Code: Select all

tux gcc # cat config
CURRENT=i686-pc-linux-gnu-4.1.1
tux gcc # cat config-i586-pc-linux-gnu
CURRENT=i386-pc-linux-gnu-3.3.6
tux gcc # cat config-i686-pc-linux-gnu
CURRENT=i386-pc-linux-gnu-3.3.6
tux gcc # cat i686-pc-linux-gnu-4.1.1
PATH="/usr/i686-pc-linux-gnu/gcc-bin/4.1.1"
ROOTPATH="/usr/i686-pc-linux-gnu/gcc-bin/4.1.1"
LDPATH="/usr/lib/gcc/i686-pc-linux-gnu/4.1.1"
GCCBITS="32"
MANPATH="/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/man"
INFOPATH="/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/info"
STDCXX_INCDIR="g++-v4"

Looks almost as amne's mini howto...

Step 10 - remove dead rats:

Code: Select all

tux gcc # rm config-i586-pc-linux-gnu
tux gcc # rm config-i686-pc-linux-gnu
tux gcc # rm i386-pc-linux-gnu-3.*
tux gcc # ls -la
total 9
drwxr-xr-x 2 root root  112 Sep  6 23:43 .
drwxr-xr-x 5 root root 1120 Sep  6 23:16 ..
-rw-r--r-- 1 root root   32 Sep  6 22:50 config
-rw-r--r-- 1 root root  292 Sep  6 22:45 i686-pc-linux-gnu-4.1.1

Step 11 - run update and check everything is sane:

Code: Select all

tux gcc # env-update && source /etc/profile
>>> Regenerating /etc/ld.so.cache...
tux gcc # grep 586 /etc/env.d/
tux gcc # grep 386 /etc/env.d/
tux gcc #

Step 12 - re-emerge libtool:

Code: Select all

tux gcc # emerge -av1 libtool

Step 13 - fix libtool:

Code: Select all

tux gcc # fix_libtool_files.sh 4.1.1 --oldarch i386-pc-linux-gnu
...
tux gcc # fix_libtool_files.sh 4.1.1 --oldarch i586-pc-linux-gnu

Step 14 - emerge glibc:

Code: Select all

tux gcc # emerge glibc

It seems to be working. I'll post the results tomorrow as I'm going to sleep.

Goodnight.


Back to the post:
So, I finally managed to successfully emerge glibc!!

I then tried to

Code: Select all

tux gcc # emerge -e world

but it stopped at some point (I don't recall what package could not be emerged).

I then made

Code: Select all

tux gcc # emerge -av1 python

which was probably not not needed but, hey! you never know and then

Code: Select all

tux gcc # emerge --resume --skipfirst

which is the action I will reiterate in case some other package fails to emerge.

That's all, thanks a lot to you all for your unwavering support!!

Ciao

Edit: Added some spaces to the LDPATH lines so they don't break the pagelayout. --Maedhros

[kg4ojl]

Just got distcc and ccache working, but it errors out on compiling glibc. I had to drop down to gcc 3.4.6-r1 because my servers are slackware and that's what is on them. I was wondering if there is a way to recompile your system by emerge -eav system and emerge -eav world, but leave out glibc to compile later without distcc, or later compile any other packages that have a problem with distcc?




Thank You.

[d-block1n]

Thanks sinanqapudan, this helped a bit. I appreciate it.

[G F0rce 1]

How exactly do I preform the following step?

- make sure that your gcc-config/binutils-config settings are sane and you
dont have any leftovers left behind in /etc/env.d/

I quite have checked my settings but I'm asking to be sure, this is to important to just screw up...

[sinanqapudan]

How exactly do I preform the following step?

- make sure that your gcc-config/binutils-config settings are sane and you
dont have any leftovers left behind in /etc/env.d/

I quite have checked my settings but I'm asking to be sure, this is to important to just screw up...

Have a look at Step 7 of my previous post.

Regards