1528194 - bug 1522354 broke mach configure on OpenBSD

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Landry Breuil (:gaston)]

Since ~2 weeks my m-c buildbot fails to pass configure, mach configure just returns without saying nothing, with an exit 1 code.

Did some bisecting that points at https://hg.mozilla.org/mozilla-central/rev/008b78c1e2b2 from bug 1522354 - https://hg.mozilla.org/mozilla-central/rev/c7b3aae27ca1 allows me to run mach configure, https://hg.mozilla.org/mozilla-central/rev/008b78c1e2b2 doesnt

Comment 1

[Landry Breuil (:gaston)]

$build/autoconf/config.guess
amd64-unknown-openbsd6.4

according to config.log the default --host value is x86_64-unknown-openbsd6.4 and that seems to be the source of the problem according to :glandium.

Comment 2

[Mike Hommey [:glandium]]

Reproducible by replacing build/autoconf/config.guess with the following script:

#!/bin/sh
echo amd64-unknown-openbsd6.4

Comment 3

[Mike Hommey [:glandium]]

Workaround:

ac_add_options --host=x86_64-unknown-openbsd6.4

in .mozconfig

Comment 4

[Landry Breuil (:gaston)]

awkward, as i'm never going to remember to replace it for openbsd6.5 in some months... so not really acceptable as a longterm fix :/

Comment 5

[Mike Hommey [:glandium]]

Ironically, running the good old fashion does print out what's going on:

$ mkdir obj
$ cd obj
$ ../configure
Creating Python environment
New python executable in /home/glandium/gecko/obj/_virtualenvs/init/bin/python2.7
Also creating executable in /home/glandium/gecko/obj/_virtualenvs/init/bin/python
Installing setuptools, pip, wheel...done.
running build_ext
copying build/lib.linux-x86_64-2.7/psutil/_psutil_linux.so -> psutil
copying build/lib.linux-x86_64-2.7/psutil/_psutil_posix.so -> psutil
Error processing command. Ignoring because optional. (optional:packages.txt:comm/build/virtualenv_packages.txt)\
Reexecuting in the virtualenv
Adding configure options from /home/glandium/gecko/.mozconfig
checking for vcs source checkout... git
checking for a shell... /bin/sh
checking for host system type...
ERROR: Unknown CPU type: amd64

The other problem is that mach eats that since bug 1522788

Comment 6

[Mike Hommey [:glandium]]

Attachment: Bug 1528194 - Print mach-invoked pseudo-configure output when it fails.

Since bug 1522788, mach invokes a part of configure as part of getting
mozconfig and target information for its own purpose. The problem is
that the sandboxed code may sys.exit(), which then makes mach silently
exit.

So when the sandboxed configure code does sys.exit(), instead of
silently failing, we catch the exit call, and print out what we
captured.

Comment 7

[Mike Hommey [:glandium]]

Attachment: Bug 1528194 - Run config.sub when split_target fails when not running it.

In bug 1522354, we changed host and target detection to not invoke
config.sub, assuming the output from config.guess would satisfy our
needs in split_target.

It turns out that on some plaforms, that doesn't work out, so, while we
still skip config.sub, we now catch errors from split_target when doing
so, and try again after running config.sub when split_target fails.

Depends on D19936

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/b14e2c05f638
Print mach-invoked pseudo-configure output when it fails. r=mshal
https://hg.mozilla.org/integration/mozilla-inbound/rev/20edea24a191
Run config.sub when split_target fails when not running it. r=mshal

Comment 9

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/b14e2c05f638
https://hg.mozilla.org/mozilla-central/rev/20edea24a191