Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 513042 - sys-devel/gcc: updating in a mips n64-only system produces a n32-build
Summary: sys-devel/gcc: updating in a mips n64-only system produces a n32-build
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: MIPS Linux
: Normal major (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
Depends on: 477956
Blocks:
  Show dependency tree
 
Reported: 2014-06-12 11:26 UTC by Sergey Popov
Modified: 2017-12-09 19:05 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sergey Popov gentoo-dev 2014-06-12 11:26:36 UTC
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)
Comment 1 Joshua Kinard gentoo-dev 2014-06-12 18:33:14 UTC
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.
Comment 2 Sergey Popov gentoo-dev 2014-06-13 22:34:19 UTC
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.
Comment 3 Markos Chandras (RETIRED) gentoo-dev 2014-06-14 12:48:24 UTC
(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/
Comment 4 SpanKY gentoo-dev 2014-06-15 06:01:52 UTC
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.
Comment 5 Matt Turner gentoo-dev 2014-06-15 17:11:59 UTC
(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.
Comment 6 Sergey Popov gentoo-dev 2014-06-16 07:53:08 UTC
(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 :-(
Comment 7 Sergey Popov gentoo-dev 2014-06-16 16:14:47 UTC
(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
Comment 8 Matt Turner gentoo-dev 2014-06-16 17:54:31 UTC
(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.
Comment 9 Sergey Popov gentoo-dev 2014-06-17 06:11:58 UTC
(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}"