This is the outcome from /tmp/stage1root as produced for a mipsel catalyst build # ls -la /var/tmp/catalyst/tmp/default/stage1-mips32r2el-20130820/tmp/stage1root/usr/bin/|grep mipsel lrwxrwxrwx 1 root root 72 Aug 21 10:55 c++-4.7.3 -> /usr/mipsel-unknown-linux-gnu/gcc-bin/4.7.3/mipsel-unknown-linux-gnu-c++ lrwxrwxrwx 1 root root 72 Aug 21 10:55 cpp-4.7.3 -> /usr/mipsel-unknown-linux-gnu/gcc-bin/4.7.3/mipsel-unknown-linux-gnu-cpp lrwxrwxrwx 1 root root 72 Aug 21 10:55 g++-4.7.3 -> /usr/mipsel-unknown-linux-gnu/gcc-bin/4.7.3/mipsel-unknown-linux-gnu-g++ lrwxrwxrwx 1 root root 72 Aug 21 10:55 gcc-4.7.3 -> /usr/mipsel-unknown-linux-gnu/gcc-bin/4.7.3/mipsel-unknown-linux-gnu-gcc lrwxrwxrwx 1 root root 73 Aug 21 10:55 gcov-4.7.3 -> /usr/mipsel-unknown-linux-gnu/gcc-bin/4.7.3/mipsel-unknown-linux-gnu-gcov lrwxrwxrwx 1 root root 72 Aug 21 10:55 mipsel-unknown-linux-gnu-c++-4.7.3 -> /usr/mipsel-unknown-linux-gnu/gcc-bin/4.7.3/mipsel-unknown-linux-gnu-c++ lrwxrwxrwx 1 root root 72 Aug 21 10:55 mipsel-unknown-linux-gnu-cpp-4.7.3 -> /usr/mipsel-unknown-linux-gnu/gcc-bin/4.7.3/mipsel-unknown-linux-gnu-cpp lrwxrwxrwx 1 root root 72 Aug 21 10:55 mipsel-unknown-linux-gnu-g++-4.7.3 -> /usr/mipsel-unknown-linux-gnu/gcc-bin/4.7.3/mipsel-unknown-linux-gnu-g++ lrwxrwxrwx 1 root root 72 Aug 21 10:55 mipsel-unknown-linux-gnu-gcc-4.7.3 -> /usr/mipsel-unknown-linux-gnu/gcc-bin/4.7.3/mipsel-unknown-linux-gnu-gcc lrwxrwxrwx 1 root root 73 Aug 21 10:55 mipsel-unknown-linux-gnu-gcov-4.7.3 -> /usr/mipsel-unknown-linux-gnu/gcc-bin/4.7.3/mipsel-unknown-linux-gnu-gcov As you can see, there is no 'gcc' in there so stage2 will fail to build because mipsel-unknown-linux-gnu-gcc does not exist. This is only reproducible in mipsel O32 build stages. MIPS64el/n32 builds gcc fine (same portage snapshot) Building gcc on a regular stage3 tarball seems to install everything fine. Could someome help me debug this on the toolchain eclasses? Do you have any ideas? This is with the default/linux/mips/13.0/mipsel profile. If you need more information please let me know
My estimation is that this part of the eclass might be causing the troubles dodir /usr/bin cd "${D}"${BINPATH} # Ugh: we really need to auto-detect this list. # It's constantly out of date. for x in cpp gcc g++ c++ gcov g77 gcj gcjh gfortran gccgo ; do # For some reason, g77 gets made instead of ${CTARGET}-g77... # this should take care of that [[ -f ${x} ]] && mv ${x} ${CTARGET}-${x} if [[ -f ${CTARGET}-${x} ]] ; then if ! is_crosscompile ; then ln -sf ${CTARGET}-${x} ${x} dosym ${BINPATH}/${CTARGET}-${x} \ /usr/bin/${x}-${GCC_CONFIG_VER} fi # Create versioned symlinks dosym ${BINPATH}/${CTARGET}-${x} \ /usr/bin/${CTARGET}-${x}-${GCC_CONFIG_VER} fi if [[ -f ${CTARGET}-${x}-${GCC_CONFIG_VER} ]] ; then rm -f ${CTARGET}-${x}-${GCC_CONFIG_VER} ln -sf ${CTARGET}-${x} ${CTARGET}-${x}-${GCC_CONFIG_VER} fi done I am going to investigate more
I guess i was wrong. This part of the eclass does not seem to be related. It seems the non-versioned files are installed by gcc makefiles.
Portage 2.2.0 (default/linux/mips/13.0/mipsel, gcc-4.6.4, glibc-2.17, 3.4.27-rt37-Cavium-Octeon mips64) ================================================================= System uname: Linux-3.4.27-rt37-Cavium-Octeon-mips64-Cavium_Octeon_II_V0.9-with-gentoo-2.2 KiB Mem: 2044556 total, 710128 free KiB Swap: 2097144 total, 2070136 free Timestamp of tree: Tue, 20 Aug 2013 07:45:01 +0000 ld GNU ld (GNU Binutils) 2.23.2 app-shells/bash: 4.2_p45 dev-lang/python: 2.7.5-r2 sys-apps/baselayout: 2.2 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.69 sys-devel/automake: 1.12.6, 1.13.4 sys-devel/binutils: 2.23.2 sys-devel/gcc: 4.6.4, 4.7.3 sys-devel/gcc-config: 1.8 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.10 (virtual/os-headers) sys-libs/glibc: 2.17 Repositories: gentoo ACCEPT_KEYWORDS="mips ~mips" ACCEPT_LICENSE="* -@EULA" CBUILD="mipsel-unknown-linux-gnu" CFLAGS="-O2 -march=mips32r2 -mabi=32 -mplt -pipe" CHOST="mipsel-unknown-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/gentoo-release /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -march=mips32r2 -mabi=32 -mplt -pipe" DISTDIR="/usr/portage/distfiles" FCFLAGS="" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" FFLAGS="" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="C" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j7" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" USE="build cxx mips unicode" ELIBC="glibc" KERNEL="linux" PYTHON_TARGETS="python2_7" USERLAND="GNU" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, SYNC, USE_PYTHON
Created attachment 356710 [details] build.log.tar.gz build.log attached
looks like your host system/tarball is broken: /usr/bin/gcc-config: line 18: /etc/init.d/functions.sh: No such file or directory gcc-config: Could not source /etc/init.d/functions.sh!
(In reply to SpanKY from comment #5) > looks like your host system/tarball is broken: > > /usr/bin/gcc-config: line 18: /etc/init.d/functions.sh: No such file or > directory > gcc-config: Could not source /etc/init.d/functions.sh! I thought this was normal because openrc is not installed as part of stage1. Probably something gone wrong during update_seed ? Let me see what's going on.
Ok seems like emerging openrc on the real root ROOT=/ fixes the problem. Something must have gone wrong during update_seed and openrc got removed. Closing as INVALID. Sorry for the noise.
Even though the original bug report sounds like invalid, this seems similar to #373219. It seems gcc-config should depend on openrc since it needs functions.sh to work properly. Maybe you should consider adding the missing dependency?
(In reply to Markos Chandras from comment #8) this is bug 373219. adding the openrc dep to gcc-config isn't going to happen.
