Bug 910199 – sys-apps/sandbox-2.34: fails during ./configure on MIPS multilib in catalyst stage3

• Product: Gentoo Linux
• Status: RESOLVED INVALID

[Description Joshua Kinard 2023-07-10 18:17:49 UTC]

Created attachment 865362 [details]
config.log

This one has me stumped.  On a full catalyst run of a MIPS multilib environment, where the three ABIs are o32, n32, and n64, with n32 being the default/preferred ABI, sandbox-2.34 will successfully compile during stage1 and stage2, but on stage3, it fails during ./configure with this:

>  * Package:    sys-apps/sandbox-2.34:0
>  * Repository: gentoo
>  * Maintainer: [e-mail]
>  * USE:        abi_mips_n32 abi_mips_n64 abi_mips_o32 elibc_glibc kernel_linux mips nnp
>  * FEATURES:   preserve-libs userpriv
> >>> Unpacking source...
> >>> Unpacking sandbox-2.34.tar.xz to /var/tmp/portage/sys-apps/sandbox-2.34/work
> >>> Source unpacked in /var/tmp/portage/sys-apps/sandbox-2.34/work
> >>> Preparing source in /var/tmp/portage/sys-apps/sandbox-2.34/work/sandbox-2.34 ...
> >>> Source prepared.
> >>> Configuring source in /var/tmp/portage/sys-apps/sandbox-2.34/work/sandbox-2.34 ...
>  * abi_mips_n64.n64: running multilib-minimal_abi_src_configure
>  * econf: updating sandbox-2.34/config.guess with /usr/share/gnuconfig/config.guess
>  * econf: updating sandbox-2.34/config.sub with /usr/share/gnuconfig/config.sub
> /var/tmp/portage/sys-apps/sandbox-2.34/work/sandbox-2.34/configure --prefix=/usr --build=mips64-unknown-linux-gnuabi64 --host=mips64-unknown-linux-gnuabi64 --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --disable-silent-rules --docdir=/usr/share/doc/sandbox-2.34 --htmldir=/usr/share/doc/sandbox-2.34/html --with-sysroot=/ --libdir=/usr/lib64
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for a race-free mkdir -p... /bin/mkdir -p
> checking for gawk... gawk
> checking whether make sets $(MAKE)... yes
> checking whether make supports nested variables... yes
> checking whether make supports nested variables... (cached) yes
> checking environment state... ok
> checking for mips64-unknown-linux-gnuabi64-gcc... mips64-unknown-linux-gnu-gcc -mabi=64
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables...
> checking whether we are cross compiling... configure: error: in `/var/tmp/portage/sys-apps/sandbox-2.34/work/sandbox-2.34-abi_mips_n64.n64':
> configure: error: cannot run C compiled programs.
> If you meant to cross compile, use `--host'.
> See `config.log' for more details
> 
> !!! Please attach the following file when seeking support:
> !!! /var/tmp/portage/sys-apps/sandbox-2.34/work/sandbox-2.34-abi_mips_n64.n64/config.log
>  * ERROR: sys-apps/sandbox-2.34::gentoo failed (configure phase):
>  *   econf failed
>  *
>  * Call stack:
>  *               ebuild.sh, line  136:  Called src_configure
>  *             environment, line 2135:  Called multilib-minimal_src_configure
>  *             environment, line 1479:  Called multilib_foreach_abi 'multilib-minimal_abi_src_configure'
>  *             environment, line 1729:  Called multibuild_foreach_variant '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_configure'
>  *             environment, line 1434:  Called _multibuild_run '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_configure'
>  *             environment, line 1432:  Called _multilib_multibuild_wrapper 'multilib-minimal_abi_src_configure'
>  *             environment, line  487:  Called multilib-minimal_abi_src_configure
>  *             environment, line 1473:  Called multilib_src_configure
>  *             environment, line 1950:  Called econf
>  *        phase-helpers.sh, line  732:  Called __helpers_die 'econf failed'
>  *   isolated-functions.sh, line  112:  Called die
>  * The specific snippet of code:
>  *              die "$@"
>  *
>  * If you need support, post the output of `emerge --info '=sys-apps/sandbox-2.34::gentoo'`,
>  * the complete build log and the output of `emerge -pqv '=sys-apps/sandbox-2.34::gentoo'`.
>  * If configure failed with a 'cannot run C compiled programs' error, try this:
>  * FEATURES='-sandbox -usersandbox' emerge sandbox
>  * The complete build log is located at '/var/tmp/portage/sys-apps/sandbox-2.34/temp/build.log'.
>  * The ebuild environment file is located at '/var/tmp/portage/sys-apps/sandbox-2.34/temp/environment'.
>  * Working directory: '/var/tmp/portage/sys-apps/sandbox-2.34/work/sandbox-2.34-abi_mips_n64.n64'
>  * S: '/var/tmp/portage/sys-apps/sandbox-2.34/work/sandbox-2.34'

This is under a Qemu environment setup by catalyst.  sandbox-2.34 works fine on my other five mips chroots, which are all single-ABI (o32, n32 x3, and one musl/o32).  The config.log output says it failed because it could not find the 'conftest' binary generated by the configure script to execute.  There doesn't appear to have been an error generated by the compiler when it emitted the binary, so I am unsure of the root cause.

Dropping into my multilib chroot and building sandbox-2.34 manually works fine, so it may be something unique to the catalyst environment that is also interfering as well.  It's been doing this since at least sandbox-2.31.

[Comment 1 Mike Gilbert 2023-07-10 18:27:36 UTC]

Is binfmt-misc configured for all 3 ABIs?

Do you have appropriate qemu-user binaries in /usr/bin for all 3 ABIs?

Is catalyst copying all necessary qemu-user binaries before chrooting?

[Comment 2 Joshua Kinard 2023-07-10 20:37:21 UTC]

(In reply to Mike Gilbert from comment #1)
> Is binfmt-misc configured for all 3 ABIs?
> 
binfmt-misc is configured on the host-side as far as I am aware, and it works for all six manual chroots and catalyst is able to build approximately ~75% of the stage3 multilib before it bails on sandbox.  If binfmt-misc wasn't configured at all, or configured incorrectly, I am doubtful I'd have gotten that far along...

> Do you have appropriate qemu-user binaries in /usr/bin for all 3 ABIs?
> 
> Is catalyst copying all necessary qemu-user binaries before chrooting?
> 
For my manual chroots, I have a custom script that mounts/umounts necessary directories before chrooting in, and it also verifies that all six qemu-mips* binaries in the chroot are present and up-to-date, otherwise, it copies them in from the host.

In the stage3 catalyst chroot's case, it only has "qemu-mipsn32" copied in, as I was under the assumption that the "interpreter" directive in a spec file only took a single argument.  Which seems to work for most cases?

That said, it does look like the "interpreter" directive accepts multiple arguments, so I am re-running the stage3 attempt with the three applicable ABI qemu bins specified to see if that fixes things.

Will update in a few hours.  Have to nuke the stage3 chroot from orbit to get it to pick up the change to the spec file.

[Comment 3 Mike Gilbert 2023-07-10 20:48:10 UTC]

(In reply to Joshua Kinard from comment #2)
> In the stage3 catalyst chroot's case, it only has "qemu-mipsn32" copied in,
> as I was under the assumption that the "interpreter" directive in a spec
> file only took a single argument.  Which seems to work for most cases?

It works fine when you are only executing code for a single ABI.

When not cross-compiling, the sandbox configure script attempts to execute code for each enabled ABI. So, you will need multiple qemu binaries to cover that.

[Comment 4 Joshua Kinard 2023-07-11 02:29:57 UTC]

(In reply to Mike Gilbert from comment #3)
> (In reply to Joshua Kinard from comment #2)
> > In the stage3 catalyst chroot's case, it only has "qemu-mipsn32" copied in,
> > as I was under the assumption that the "interpreter" directive in a spec
> > file only took a single argument.  Which seems to work for most cases?
> 
> It works fine when you are only executing code for a single ABI.
> 
> When not cross-compiling, the sandbox configure script attempts to execute
> code for each enabled ABI. So, you will need multiple qemu binaries to cover
> that.
Yeah, looks like getting all three interpreters into the stage3 fixed it.  Going to mark this one as RESOLVED::PEBKAC (we need this as a legit resolution status).  Thanks!