Bug 549592 – sys-devel/gnuconfig: mips32-* tuples turned into mips642-*

• Status: RESOLVED INVALID
• Product: Gentoo Linux

[Description ytrezq 2015-05-15 20:16:02 UTC]

It doesn’t come from crossdev itself but I wasn’t able to find the sub-component reference which call setenv UNAME_m. One of the major results is this inside configure scripts runned by mips32-uclibc-linux-emerge :
>>> Source prepared.
>>> Configuring source in /usr/mips32-uclibc-linux/tmp/portage/sys-libs/libcap-ng-0.7.4/work/libcap-ng-0.7.4 ...
>>> Working in BUILD_DIR: "/usr/mips32-uclibc-linux/tmp/portage/sys-libs/libcap-ng-0.7.4/work/libcap-ng-0.7.4_build"
 * econf: updating libcap-ng-0.7.4/config.guess with /usr/share/gnuconfig/config.guess
 * econf: updating libcap-ng-0.7.4/config.sub with /usr/share/gnuconfig/config.sub
/usr/mips32-uclibc-linux/tmp/portage/sys-libs/libcap-ng-0.7.4/work/libcap-ng-0.7.4/configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=mips32-uclibc-linux --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-silent-rules --disable-dependency-tracking --docdir=/usr/share/doc/libcap-ng-0.7.4 --enable-shared --enable-static --without-python
configure: loading site script /usr/share/config.site
Configuring libcap-ng
checking build system type... x86_64-pc-linux-gnu
checking host system type... mips642-uclibc-linux-gnu
checking target system type... mips642-uclibc-linux-gnu

This doesn’t prevent most packages from building and running, but some of them contains manually written assembly which is partially generated according to system settings. like libcap-ng-0.7.4 here where mixed c/assembly was put in some generated source files and it typically generate that kind of error:
{standard input}: Assembler messages:
{standard input}:15: Warning: No .cprestore pseudo-op used in PIC code
{standard input}:26: Warning: No .cprestore pseudo-op used in PIC code
{standard input}:37: Warning: No .cprestore pseudo-op used in PIC code
{standard input}:130: Error: bad expression
{standard input}:130: Error: bad expression
{standard input}:130: Error: illegal operands `addiu'
{standard input}:176: Error: bad expression
{standard input}:176: Error: bad expression
{standard input}:176: Error: illegal operands `addiu'
{standard input}:222: Error: bad expression
{standard input}:222: Error: bad expression
{standard input}:222: Error: illegal operands `addiu'
{standard input}:268: Error: bad expression
{standard input}:268: Error: bad expression
{standard input}:268: Error: illegal operands `addiu'
{standard input}:316: Error: bad expression
{standard input}:316: Error: bad expression
{standard input}:316: Error: illegal operands `addiu'
{standard input}:379: Error: bad expression
{standard input}:379: Error: bad expression
{standard input}:379: Error: illegal operands `addiu'
{standard input}:439: Error: bad expression
{standard input}:439: Error: bad expression
{standard input}:439: Error: illegal operands `addiu'
{standard input}:499: Error: bad expression
{standard input}:499: Error: bad expression
{standard input}:499: Error: illegal operands `addiu'
{standard input}:666: Error: bad expression
{standard input}:666: Error: bad expression
{standard input}:666: Error: illegal operands `addiu'
{standard input}:729: Error: bad expression
{standard input}:729: Error: bad expression
{standard input}:729: Error: illegal operands `addiu'
{standard input}:837: Error: bad expression
{standard input}:837: Error: bad expression
{standard input}:837: Error: illegal operands `addiu'
{standard input}:905: Error: bad expression
{standard input}:905: Error: bad expression
{standard input}:905: Error: illegal operands `addiu'
{standard input}:1011: Error: bad expression
{standard input}:1011: Error: bad expression
{standard input}:1011: Error: illegal operands `addiu'
{standard input}:1118: Error: bad expression
{standard input}:1118: Error: bad expression
{standard input}:1118: Error: illegal operands `addiu'
{standard input}:1198: Error: bad expression
{standard input}:1198: Error: bad expression
{standard input}:1198: Error: illegal operands `addiu'
{standard input}:1238: Error: bad expression
{standard input}:1238: Error: bad expression
{standard input}:1238: Error: illegal operands `addiu'
{standard input}:1261: Error: bad expression
{standard input}:1261: Error: bad expression
{standard input}:1261: Error: illegal operands `addiu'
{standard input}:1330: Error: bad expression
{standard input}:1330: Error: bad expression
{standard input}:1330: Error: illegal operands `addiu'
{standard input}:1412: Error: bad expression
{standard input}:1412: Error: bad expression
{standard input}:1412: Error: illegal operands `addiu'
{standard input}:1618: Error: bad expression
{standard input}:1618: Error: bad expression
{standard input}:1618: Error: illegal operands `addiu'
{standard input}:1692: Error: bad expression
{standard input}:1692: Error: bad expression
{standard input}:1692: Error: illegal operands `addiu'
{standard input}:1744: Error: bad expression
{standard input}:1744: Error: bad expression
{standard input}:1744: Error: illegal operands `addiu'
{standard input}:1834: Error: bad expression
{standard input}:1834: Error: bad expression
{standard input}:1834: Error: illegal operands `addiu'
{standard input}:1999: Error: bad expression
{standard input}:1999: Error: bad expression
{standard input}:1999: Error: illegal operands `addiu'
{standard input}:2110: Error: bad expression
{standard input}:2110: Error: bad expression
{standard input}:2110: Error: illegal operands `addiu'
{standard input}:2171: Error: bad expression
{standard input}:2171: Error: bad expression
{standard input}:2171: Error: illegal operands `addiu'
{standard input}:2203: Error: bad expression
{standard input}:2203: Error: bad expression
{standard input}:2203: Error: illegal operands `addiu'
{standard input}:2312: Error: bad expression
{standard input}:2312: Error: bad expression
{standard input}:2312: Error: illegal operands `addiu'
{standard input}:2439: Error: bad expression
{standard input}:2439: Error: bad expression
{standard input}:2439: Error: illegal operands `addiu'
{standard input}:2467: Error: bad expression
{standard input}:2467: Error: bad expression
{standard input}:2467: Error: illegal operands `addiu'
{standard input}:2541: Error: bad expression
{standard input}:2541: Error: bad expression
{standard input}:2541: Error: illegal operands `addiu'
{standard input}:2569: Error: bad expression
{standard input}:2569: Error: bad expression
{standard input}:2569: Error: illegal operands `addiu'
{standard input}:2643: Error: bad expression
{standard input}:2643: Error: bad expression
{standard input}:2643: Error: illegal operands `addiu'
{standard input}:2675: Error: bad expression
{standard input}:2675: Error: bad expression
{standard input}:2675: Error: illegal operands `addiu'
{standard input}:2711: Error: bad expression
{standard input}:2711: Error: bad expression
{standard input}:2711: Error: illegal operands `addiu'
{standard input}:2729: Error: bad expression
{standard input}:2729: Error: bad expression
{standard input}:2729: Error: illegal operands `addiu'
{standard input}:2747: Error: bad expression
{standard input}:2747: Error: bad expression
{standard input}:2747: Error: illegal operands `addiu'
{standard input}:2837: Error: bad expression
{standard input}:2837: Error: bad expression
{standard input}:2837: Error: illegal operands `addiu'
{standard input}:3035: Error: bad expression
{standard input}:3035: Error: bad expression
{standard input}:3035: Error: illegal operands `addiu'
{standard input}:3063: Error: bad expression
{standard input}:3063: Error: bad expression
{standard input}:3063: Error: illegal operands `addiu'
{standard input}:3112: Error: bad expression
{standard input}:3112: Error: bad expression
{standard input}:3112: Error: illegal operands `addiu'
{standard input}:3157: Error: bad expression
{standard input}:3157: Error: bad expression
{standard input}:3157: Error: illegal operands `addiu'
{standard input}:3191: Error: bad expression
{standard input}:3191: Error: bad expression
{standard input}:3191: Error: illegal operands `addiu'
{standard input}:3264: Error: bad expression
{standard input}:3264: Error: bad expression
{standard input}:3264: Error: illegal operands `addiu'
{standard input}:3375: Error: bad expression
{standard input}:3375: Error: bad expression
{standard input}:3375: Error: illegal operands `addiu'
{standard input}:3416: Error: bad expression
{standard input}:3416: Error: bad expression
{standard input}:3416: Error: illegal operands `addiu'
{standard input}:3526: Error: bad expression
{standard input}:3526: Error: bad expression
{standard input}:3526: Error: illegal operands `addiu'
{standard input}:3558: Error: bad expression
{standard input}:3558: Error: bad expression
{standard input}:3558: Error: illegal operands `addiu'
{standard input}:3616: Error: bad expression
{standard input}:3616: Error: bad expression
{standard input}:3616: Error: illegal operands `addiu'
{standard input}:3644: Error: bad expression
{standard input}:3644: Error: bad expression
{standard input}:3644: Error: illegal operands `addiu'
{standard input}:3686: Error: bad expression
{standard input}:3686: Error: bad expression
{standard input}:3686: Error: illegal operands `addiu'
{standard input}:3714: Error: bad expression
{standard input}:3714: Error: bad expression
{standard input}:3714: Error: illegal operands `addiu'
{standard input}:3758: Error: bad expression
{standard input}:3758: Error: bad expression
{standard input}:3758: Error: illegal operands `addiu'
{standard input}:3776: Error: bad expression
{standard input}:3776: Error: bad expression
{standard input}:3776: Error: illegal operands `addiu'
{standard input}:3817: Error: bad expression
{standard input}:3817: Error: bad expression
{standard input}:3817: Error: illegal operands `addiu'
{standard input}:3845: Error: bad expression
{standard input}:3845: Error: bad expression
{standard input}:3845: Error: illegal operands `addiu'
{standard input}:3877: Error: bad expression
{standard input}:3877: Error: bad expression
{standard input}:3877: Error: illegal operands `addiu'
{standard input}:3894: Error: bad expression
{standard input}:3894: Error: bad expression
{standard input}:3894: Error: illegal operands `addiu'
{standard input}:3933: Error: bad expression
{standard input}:3933: Error: bad expression
{standard input}:3933: Error: illegal operands `addiu'
{standard input}:4299: Error: bad expression
{standard input}:4299: Error: bad expression
{standard input}:4299: Error: illegal operands `addiu'


=================================================================
                         System Settings
=================================================================
System uname: Linux-3.16.0-rc7-ck2-x86_64-Intel-R-_Core-TM-_i5-3450S_CPU_@_2.80GHz-with-gentoo-2.2
KiB Mem:    15854796 total,  11316316 free
KiB Swap:   26675928 total,  26286052 free
Timestamp of tree: Sun, 10 May 2015 21:30:01 +0000
Repositories: gentoo
ACCEPT_KEYWORDS="mips ~mips"
ACCEPT_LICENSE="* -@EULA"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-fmodulo-sched -fmodulo-sched-allow-regmoves -Os -mips32 -march=mips32 -mtune=mips32 -membedded-data -mips16 -pipe -freorder-blocks-and-partition"
CHOST="mips32-uclibc-linux"
CONFIG_PROTECT="/etc"
CONFIG_PROTECT_MASK="/etc/env.d"
CPPFLAGS="-fmodulo-sched -fmodulo-sched-allow-regmoves -Os -mips32 -march=mips32 -mtune=mips32 -membedded-data -mips16 -pipe -freorder-blocks-and-partition"
CXXFLAGS="-fmodulo-sched -fmodulo-sched-allow-regmoves -Os -mips32 -march=mips32 -mtune=mips32 -membedded-data -mips16 -pipe -freorder-blocks-and-partition"
DISTDIR="/usr/portage/distfiles"
FCFLAGS="-fmodulo-sched -fmodulo-sched-allow-regmoves -Os -mips32 -march=mips32 -mtune=mips32 -membedded-data -mips16 -pipe -freorder-blocks-and-partition"
FEATURES="assume-digests binpkg-logs buildpkg config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news nodoc nostrip parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync"
FFLAGS="-fmodulo-sched -fmodulo-sched-allow-regmoves -Os -mips32 -march=mips32 -mtune=mips32 -membedded-data -mips16 -pipe -freorder-blocks-and-partition"
GENTOO_MIRRORS="http://distfiles.gentoo.org"
LDFLAGS="-Wl,--as-needed -Wl,-O1"
MAKEOPTS="-j3"
PKGDIR="/usr/mips32-uclibc-linux/packages/"
PORTAGE_CONFIGROOT="/usr/mips32-uclibc-linux/"
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="/usr/mips32-uclibc-linux/tmp/"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY=""
USE="acl apng bzip2 cscope cytune edit fdformat fixed-point gmp gnutls gpm graphite hardfloat i18n iconv icu idn ipc ipv6 jpeg kdrive less lto lzma make-symlinks math mclib mdev minimal minizip mips mipsfpu multicall multitarget ncurses networking nls nptl oom pcre pgo plugins png python3 savedconfig sharedmem ssl static-libs svg tiff tinfo tls tty-helpers uclibc-compat unicode utils vim-pager wide-unicode wordexp zlib" CURL_SSL="gnutls" ELIBC="uclibc" INPUT_DEVICES="evdev mouse keyboard tslib" KERNEL="linux" LINGUAS="fr" PYTHON_SINGLE_TARGET="python3_4" PYTHON_TARGETS="python3_4 python2_7" USERLAND="GNU" VIDEO_CARDS="fbdev"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, SYNC, USE_PYTHON

[Comment 1 Joshua Kinard 2015-05-16 02:18:26 UTC]

CHOST for MIPS32r* should be "mips-unknown-linux-<LIBC>", where <LIBC> is one of 'gnu', 'uclibc', or 'musl'.  Is your board mips32r1 or mips32r2?  I'd pass the full ISA target to -march and -mtune to avoid confusing the compiler as well.

[Comment 2 SpanKY 2015-05-16 03:39:09 UTC]

mips3-xxx is a valid arch and the gnu config project turns that into mips64-xxx.  so when you use mips32-xxx, it changes {mips3}2-xxx into {mips64}2-xxx.

as Kumba said, this tuple is invalid.  use CFLAGS instead to control the ISA.

[Comment 3 ytrezq 2015-05-16 10:48:08 UTC]

(In reply to Joshua Kinard from comment #1)
> CHOST for MIPS32r* should be "mips-unknown-linux-<LIBC>", where <LIBC> is
> one of 'gnu', 'uclibc', or 'musl'.  Is your board mips32r1 or mips32r2?  I'd
> pass the full ISA target to -march and -mtune to avoid confusing the
> compiler as well.

-march=mips32 with -mips32 IN CFLAGS is the only valid way to tell the compiler to generate code for mips32 release 1.

It also appear the example here with libcap-ng doesn’t come from the mips642 tuple.

[Comment 4 ytrezq 2015-05-16 10:58:41 UTC]

(In reply to SpanKY from comment #2)
> CHOST for MIPS32r* should be "mips-unknown-linux-<LIBC>", where <LIBC> is one of 'gnu', 'uclibc', or 'musl'

Maybe, but crossdev requires an argument which need to contain ARCH VENDOR OS LIBC.
Though I might used an incorrect vendor, using the desired ISA after mips is the way to specify the target ISA for the generated toolchain.

So while it is true I didn’t used mips32-unknown-linux-uclibc, using mips-unknown-linux-uclibc with crossdev would generate a toolchain for a default ISA which is not mips32.

[Comment 5 SpanKY 2015-05-16 12:56:19 UTC]

(In reply to lcellier from comment #4)

crossdev merely tries to provide documentation for the existing tuple standards in a format that is easy to understand.  in the end, it simply passes the tuples down to the existing projects (most notably GNU config).  crossdev itself imposes no additional requirements on the form of the tuple.

if you want to have a toolchain that targets mips32 by default, you could run crossdev with a flag like:
 ... --genv 'EXTRA_ECONF="--with-arch=mips32"' ...

[Comment 6 Joshua Kinard 2015-05-16 18:06:47 UTC]

(In reply to lcellier from comment #4)
> (In reply to SpanKY from comment #2)
> > CHOST for MIPS32r* should be "mips-unknown-linux-<LIBC>", where <LIBC> is one of 'gnu', 'uclibc', or 'musl'
> 
> Maybe, but crossdev requires an argument which need to contain ARCH VENDOR
> OS LIBC.
> Though I might used an incorrect vendor, using the desired ISA after mips is
> the way to specify the target ISA for the generated toolchain.
> 
> So while it is true I didn’t used mips32-unknown-linux-uclibc, using
> mips-unknown-linux-uclibc with crossdev would generate a toolchain for a
> default ISA which is not mips32.

That's just one of the perils with MIPS, unfortunately.  The possible mixture of ISAs, ABIs, and Endians just leads to combinatorial explosion.  The general rule of thumb is you spin a cross-compiler that matches your bitness (32 or 64), endian, and libc, then pass -mabi, -march, and -mtune to drill down to your preferred target platform.  So even though the *default* ISA for mips-unknown-linux-* may not be mips32r1, you can still force that by passing -march=mips32.

I myself even learned that you can generate a mips64 compiler and still target all of the available 32-bit userlands out there by passing the correct flags, all thanks to multitarget support in binutils and gcc.  In this case, 'mips64-unknown-linux-uclibc -march=mips32 -mtune=mips32 -mabi=32 <flags> <source> -o <binary>' would work for you.

[Comment 7 ytrezq 2015-05-16 18:57:04 UTC]

> 
> I myself even learned that you can generate a mips64 compiler and still
> target all of the available 32-bit userlands out there by passing the
> correct flags, all thanks to multitarget support in binutils and gcc.  In
> this case, 'mips64-unknown-linux-uclibc -march=mips32 -mtune=mips32 -mabi=32
> <flags> <source> -o <binary>' would work for you.

I am very curious on how 32 bits programs can be linked with 64 bits only version crt1.o or crti.o. (I had crti.o no such file or directory)

Or perhaps have you modified your toolchain.eclass so flags aren’t striped?

[Comment 8 Joshua Kinard 2015-05-17 05:12:31 UTC]

(In reply to lcellier from comment #7)
> > 
> > I myself even learned that you can generate a mips64 compiler and still
> > target all of the available 32-bit userlands out there by passing the
> > correct flags, all thanks to multitarget support in binutils and gcc.  In
> > this case, 'mips64-unknown-linux-uclibc -march=mips32 -mtune=mips32 -mabi=32
> > <flags> <source> -o <binary>' would work for you.
> 
> I am very curious on how 32 bits programs can be linked with 64 bits only
> version crt1.o or crti.o. (I had crti.o no such file or directory)
> 
> Or perhaps have you modified your toolchain.eclass so flags aren’t striped?

Clarification: I learned this on kernel compiles.  Obviously, if you're using a mips64-* compiler and trying to build 32-bit userland stuff, you're going to need a 32-bit libc kicking around.  But on kernel runs, you can use a mips64-* toolchain to build 32-bit kernels, as long as you pass -mabi=32.

[Comment 9 ytrezq 2015-05-17 10:41:55 UTC]

> Clarification: I learned this on kernel compiles.  Obviously, if you're
> using a mips64-* compiler and trying to build 32-bit userland stuff, you're
> going to need a 32-bit libc kicking around.  But on kernel runs, you can use
> a mips64-* toolchain to build 32-bit kernels, as long as you pass -mabi=32.

I disagree at least for executables, It tried it myself, as creating executables relies on linking on Crtbegin.o and other files. And you should get compile errors.
There is also some shared libraries like libgcc or libstdxx or libgfortran which can no longer be compiled separately from gcc. and you need a libc for building them (which is why crossdev generate a stage 1, and install kernel headers, then build µClibc, and then build other compiler stages).
You can generate code for any ISA/ABI as long as they don’t rely on external binaries for linking (which is typically the case for the kernel).

Or perhaps it wasn’t modern ELF executables?

[Comment 10 SpanKY 2015-05-17 11:23:08 UTC]

(In reply to lcellier from comment #9)

i think you're confusing things here.  shared libraries are needed only to link, and even then just to link userland code (most of the time).  none of that matters to compiling (pure code generation) or linking completely standalone programs like a boot loader or the kernel.

it is possible to create a single toolchain that has many multilibs, we just don't generally bother.  Gentoo only cares about n32/n64/o32 in the general case.  for other ABIs, you have to use your own compiler settings.

[Comment 11 ytrezq 2015-05-17 19:25:34 UTC]

(In reply to SpanKY from comment #10)
> (In reply to lcellier from comment #9)
> 
> i think you're confusing things here.  shared libraries are needed only to
> link, and even then just to link userland code (most of the time).  none of
> that matters to compiling (pure code generation) or linking completely
> standalone programs like a boot loader or the kernel.
> 
> it is possible to create a single toolchain that has many multilibs, we just
> don't generally bother.  Gentoo only cares about n32/n64/o32 in the general
> case.  for other ABIs, you have to use your own compiler settings.

Yes I was talking about userland, not the kernel since it in my case the vendor is providing versioned proprietary kernel modules in order to get Linux running on the SoC.

I never brought compiling the bootloader or kernel couldn’t be done with a toolchain for an another ABI/ISA since only cc1/lto1 matter in that case (they are not bound to a particular ISA/ABI, and those programs often use custom ld scripts).

But for linking userland code, (not for generating .o relocatables) I need the toolchain to be using the same ISA/ABI as the target, which is achieved by using crossdev with ArchIsa-vendor-OS-libc --abis Abi

[Comment 12 Joshua Kinard 2015-05-17 20:34:25 UTC]

(In reply to lcellier from comment #11)
> 
> But for linking userland code, (not for generating .o relocatables) I need
> the toolchain to be using the same ISA/ABI as the target, which is achieved
> by using crossdev with ArchIsa-vendor-OS-libc --abis Abi

If there's some kind of change floating around out there that alters the CHOST tuple to be <arch><isa>-<vendor>-<kernel>-<libc>, then that's new and we likely won't support it until it becomes more mainstream.  We have seen 'mips64-unknown-linux-gnuabin32' before, to generate an n32-only compiler, but we don't support it since a normal 64bit toolchain is adequate for both n32 and n64, provided you build the libc (and other libs) twice for n32 and n64.

So in the end, stick with 'mips-unknown-linux-uclibc' for your CHOST tuple and make sure to pass -march=mips32 in CFLAGS/CXXFLAGS/etc, and you should have fewer problems.