This patch for gcc-3.2.2-r1.ebuild allows the ebuild to create a native gcc or a cross compiler Reproducible: Always Steps to Reproduce: 1. emerge gcc Native gcc 2. CCHOST=sparc-unknown-linux-gnu USE=build emerge gcc Build a 1st stage gcc for cross tool chain to compile the cross glibc. 3. CCHOST=sparc-unknown-linux-gnu emerge gcc Builds the 2nd stage gcc for the cross tool chain.
Created attachment 9717 [details, diff] patch for gcc-3.2.2-r1 Related to linux-headers bug 18031 binutils bug 18032 glibc bug 18033
The components of this tool chain on my system have been emerged and unmerge cleanly. I have build 8 differernt tool chains with these ebuilds. I have used this gcc ebuild to update my system compiler as well building cross compilers. So it also seems to play nice with gcc-config gcc-config --list-profiles Lists every compiler installed gcc-config sparc-unknown-linux-gnu-3.2.2 Will change the system compiler to the cross compiler.
Created attachment 9718 [details, diff] allows the 1st stage gcc to be build for ppc This patch is only for the 1st stage gcc when targeting ppc. Once glibc has been build this patch is not needed.
Created attachment 9719 [details, diff] allows the 1st stage gcc to be built for alpha This patch is for building the 1st stage gcc for alpha. Once glibc has been built this patch is not needed.
Created attachment 9720 [details, diff] allows the 1st stage gcc to be built for x86 Allows the 1st stage gcc to be built when targeting x86. Once glibc has been built this patch is not needed.
Like glibc, this gcc ebuild needs a little more review before I am ready to commit it; however, Aiken's collection of ebuilds is by far the most integrated implementation I have seen to date, and I will be trying to focus everyone's attention to these for testing and revision. Since a full cross-gcc toolchain results from the sequential installation of binutils (bug 18032), linux-headers (bug 18031), glibc (bug 18033), and finally the full gcc itself, I am marking this bug for cross-gcc as dependent on those other cross-compiling ebuilds.
I have a few small issues with this. 1) It should be cross-check ${MY_PV} and not: cross-check 3.2.2 2) Having gcc symlinks in /usr/bin will break multi-version support. 3) If it will run fix_libtool_files.sh, I will have to change it to take and optional target of CCHOST, else its gonna bork the real system stuff :/ That is it for a quick peek.
Created attachment 10248 [details, diff] 6/4/2003 patch for gcc-3.2.2-r1 After preliminary testing this ebuild will create a native gcc, a cross gcc and also be cross compiled. It is now symlinking any libs in /usr/lib/gcc-lib/$CCHOST/$PV/ to /usr/$CCHOST/lib This will allow $CCHOST-ld to find the cross libgcc* and libstdc++* with out having to set extra flags. The multi version stuff is still be looked at. The $CCHOST-gcc sym links back to /ust/bin at least give access to the cross compiler.
*** Bug 17120 has been marked as a duplicate of this bug. ***
> The multi version stuff is still be looked at. The $CCHOST-gcc sym links back > to /ust/bin at least give access to the cross compiler. Which part of NO don't you understand ? Currently gcc have issues with symlinks from /usr/bin (or where ever) to its true bin dir .. have a look at bug #8132. If you want to have access all the time, just install the $CCHOST-* binaries in the real bin dir, and not the unhosted ones, and always add this to the $PATH.
>Which part of NO don't you understand ? Where did you say NO? You did say the sym links break being able to have multiple versions. Which I agree with. I was staying with the sym links until something better came along. Up until you showed me bug 8132 I have not had not seen any problems with using the symlinks. gcc-config <cross compiler> is far too dangerous to use. I can say I have been there done that and had to recover a couple of packages because I forgot to use gcc-config to change back to the native compiler. Some of the results so far are at http://www.gentoo.org/~aiken/gentoo-cross/gentoo-cross.html#SECTION000100000000000000000 The arm and sparc cross compilers were produced by these ebuilds. Actually every compiler listed on that page excluding the linux->mingw32 and cygwin->linux compilers were produced with these ebuilds or earlier versions. I have used the sparc chroot on my machine and Zach has tried the arm chroot on his netwinder. I have also cross compiled a LFS stage1. My sparc runs a 2.2.20 kernel that was cross compiled using a 2.95.3 cross compiler that was produced in a similar manner.
Comment 7 actually ;-)
Comment on attachment 10248 [details, diff] 6/4/2003 patch for gcc-3.2.2-r1 A new patch will be posted shortly.
How important is get_number_of_jobs() in the gcc ebuild? At the moment I am only letting the ebuild use get_number_of_jobs() if building a native compiler. This is stopping this function from aborting the build. if ! cross-target && ! cross-build then # Setup -j in MAKEOPTS get_number_of_jobs fi It uses ARCH to determine which /proc/cpuinfo format to use. When building a cross toolchain or cross compiling gcc ARCH will equal the target arch not the local arch so there is a very good chance it will try using the wrong format for /proc/cpuinfo then abort the build. I have also had get_number_of_jobs() abort a build when I was targeting cris-axis-linux-gnu which is a valid target. The die message was Unknown ARCH -- cris! When I bypass get_number_of_jobs() I normaly use -j2 or -j4 with no apparent ill effect.
hi what is the current status for this? Alex
*** Bug 44731 has been marked as a duplicate of this bug. ***
Is this bug still valid? Can it be closed?
obsoleted by crossdev tool in the future? *hint*hint* sinc, Alex
no crossdev is a hack to work around a portage that cant handle cross compiling
no, we want to make crossdev not needed ... ive got work in gcc-3.4.3 ... all you have to do is: env CTARGET="sh4-pc-linux-uclibc" emerge gcc if something breaks, file a bug :)
