octocat-t1 ~ # eselect profile show Current /etc/portage/make.profile symlink: default/linux/mips/13.0/n64 octocat-t1 ~ # gcc gcc-config: error: could not run/locate 'gcc' octocat-t1 ~ # mips64-unknown-linux-gnu-gcc gcc-config: error: could not run/locate 'mips64-unknown-linux-gnu-gcc' octocat-t1 ~ # /usr/mips64-unknown-linux-gnu/gcc-bin/4.8.2/mips64-unknown-linux-gnu-gcc -bash: /usr/mips64-unknown-linux-gnu/gcc-bin/4.8.2/mips64-unknown-linux-gnu-gcc: No such file or directory octocat-t1 ~ # file /usr/mips64-unknown-linux-gnu/gcc-bin/4.8.2/mips64-unknown-linux-gnu-gcc /usr/mips64-unknown-linux-gnu/gcc-bin/4.8.2/mips64-unknown-linux-gnu-gcc: ELF 32-bit MSB executable, MIPS, N32 MIPS64 rel2 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, stripped octocat-t1 ~ # lddtree /usr/mips64-unknown-linux-gnu/gcc-bin/4.8.2/mips64-unknown-linux-gnu-gcc mips64-unknown-linux-gnu-gcc => /usr/mips64-unknown-linux-gnu/gcc-bin/4.8.2/mips64-unknown-linux-gnu-gcc (interpreter => /lib32/ld.so.1) libc.so.6 => not found ld.so.1 => not found octocat-t1 ~ # emerge -Opv gcc glibc These are the packages that would be merged, in order: [ebuild R ] sys-devel/gcc-4.8.2:4.8 USE="cxx fortran nls nptl openmp (-altivec) -awt -doc -fixed-point -gcj -go -graphite (-hardened) (-libssp) -mudflap (-multilib*) (-multislot) -nopie -nossp -objc -objc++ -objc-gc -regression-test -vanilla" 0 kB [ebuild U ] sys-libs/glibc-2.19:2.2 [2.18-r1:2.2] USE="-debug -gd (-hardened) (-multilib) -nscd -profile (-selinux) -suid -systemtap -vanilla" 0 kB GCC was later reinstalled from cross-compiled binary package, but, because of bug #477956 it is still can not be used, as on this system there are not N32 libs at all(no /lib32)
Just out of mild curiosity, do you have another gcc installed alongside gcc-4.8.2? If so, can you use gcc-config to switch to it, compile a simple test program (like hello world), then run 'ldd' on the binary and tell me if the paths link to the correct libgcc_s.so version, or if they try to link to gcc-4.8.2's libgcc_s.so? I ran into such a case while rebuilding the userland on my Octane, and just want to make sure I wasn't running into some kind of related bug. In my case, o32 w/ mips-linux-unknown-gnu. The $PATH was set so that 'mips-linux-unknown-gnu-gcc' and friends could be executed, but the linking was clearly messed up.
I am very sorry for confusion, i went through shell command history and realized that the whole situation is because i installed wrong cross-compiled binary package. Problem is that, despite of forcing n64 in any forms(CFLAGS, profile selection, etc), result compiler ABI is n32. In crossdev or neighbor n32/multilib environment with overrided ROOT and PORTAGE_CONFIGROOT(that pointing to valid n64 root with correctly selected profile). So, closing as INVALID? Or trying to dig deeper? Cause i see nothing strange in toolchain eclass that can lead to this behaviour.
(In reply to Sergey Popov from comment #2) > I am very sorry for confusion, i went through shell command history and > realized that the whole situation is because i installed wrong > cross-compiled binary package. > > Problem is that, despite of forcing n64 in any forms(CFLAGS, profile > selection, etc), result compiler ABI is n32. In crossdev or neighbor > n32/multilib environment with overrided ROOT and PORTAGE_CONFIGROOT(that > pointing to valid n64 root with correctly selected profile). > > So, closing as INVALID? Or trying to dig deeper? Cause i see nothing strange > in toolchain eclass that can lead to this behaviour. not sure if that helps at this point but maybe you can use the tinderbox packages to recover http://tinderbox.dev.gentoo.org/default-linux/mips/
i'm lost as to what this bug is trying to show. mips64-unknown-linux-gnu has always defaulted to n32 hasn't it ? and in bug 477956, we already cover the fact that gcc itself doesn't support building as n64 by default.
(In reply to SpanKY from comment #4) > i'm lost as to what this bug is trying to show. mips64-unknown-linux-gnu > has always defaulted to n32 hasn't it ? and in bug 477956, we already cover > the fact that gcc itself doesn't support building as n64 by default. That bug is actually about building gcc as an N64 binary on profiles with some other default ABI. But yeah, I don't know what is going on in this bug either.
(In reply to SpanKY from comment #4) > i'm lost as to what this bug is trying to show. mips64-unknown-linux-gnu > has always defaulted to n32 hasn't it ? and in bug 477956, we already cover > the fact that gcc itself doesn't support building as n64 by default. Right now - yes. But old stage has it in n64! Just look at stage3-mips64_n64-20130724.tar.bz2 on our mirrors. GCC built there has N64, definitely. You can, of course, close this as a duplicate of bug #477956(cause this is real culprit here). But i think impossibility to upgrade without changing profile is a different issue. I can change profile to n32/multilib and build whole stuff from there, sure, not a big deal now(when i tried everything else) (In reply to Markos Chandras from comment #3) > not sure if that helps at this point but maybe you can use the tinderbox > packages to recover > > http://tinderbox.dev.gentoo.org/default-linux/mips/ I can not find packages for BIG endian there :-(
(In reply to SpanKY from comment #4) > i'm lost as to what this bug is trying to show. mips64-unknown-linux-gnu > has always defaulted to n32 hasn't it ? and in bug 477956, we already cover > the fact that gcc itself doesn't support building as n64 by default. octocat-t1 ~ # file /usr/mips64-unknown-linux-gnu/gcc-bin/4.8.1/mips64-unknown-linux-gnu-gcc /usr/mips64-unknown-linux-gnu/gcc-bin/4.8.1/mips64-unknown-linux-gnu-gcc: ELF 64-bit MSB executable, MIPS, MIPS64 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, not stripped That's from precompiled stage3 from our mirrors
(In reply to Sergey Popov from comment #6) > (In reply to SpanKY from comment #4) > > i'm lost as to what this bug is trying to show. mips64-unknown-linux-gnu > > has always defaulted to n32 hasn't it ? and in bug 477956, we already cover > > the fact that gcc itself doesn't support building as n64 by default. > > Right now - yes. But old stage has it in n64! > > Just look at stage3-mips64_n64-20130724.tar.bz2 on our mirrors. > > GCC built there has N64, definitely. > > You can, of course, close this as a duplicate of bug #477956(cause this is > real culprit here). But i think impossibility to upgrade without changing > profile is a different issue. No, that bug is about using an n64 gcc binary on profiles where the default ABI is not n64. I'll modify its title... If you can't update gcc from the mips64_n64 stage, then that's a bug.
(In reply to Matt Turner from comment #8) > No, that bug is about using an n64 gcc binary on profiles where the default > ABI is not n64. > > I'll modify its title... > > If you can't update gcc from the mips64_n64 stage, then that's a bug. Well. according to make.defaults in arch/mips/mips64/n64(which is inherited from my profile): DEFAULT_ABI="n64" ABI="${DEFAULT_ABI}"
This does not appear to be an issue anymore with the 17.0 profiles. I upgraded from gcc 11.3.0 to 12.2.0 on a pure-n64 system, and the resulting binary is still n64. Could this be retested please?
(In reply to matoro from comment #10) > This does not appear to be an issue anymore with the 17.0 profiles. I > upgraded from gcc 11.3.0 to 12.2.0 on a pure-n64 system, and the resulting > binary is still n64. > > Could this be retested please? Should work now IMHO.
