1077625 - Building with >=103 character long $OBJDIR path triggers "creating ./config.status" and then "/bin/sh: 1: ./config.status: not found"

Status: RESOLVED DUPLICATE of bug 1052560

(Firefox Build System :: General, defect)

Description

[Daniel Holbert [:dholbert]]

STR:
 1. Try to build without a .mozconfig file

ACTUAL RESULTS: Before you get to compiling any source, you get something like this:
{
 0:23.13 checking for localeconv... (cached) yes
 0:23.16 checking for malloc_size... no
 0:23.17 checking for malloc_usable_size... (cached) yes
 0:23.17 updating cache /scratch/work/builds/mozilla-central/mozilla-central-11-11-01.13-56/mozilla/obj-x86_64-unknown-linux-gnu/config.cache
 0:23.17 creating ./config.status
 0:23.17 /bin/sh: 1: ./config.status: not found
 0:23.18 *** Fix above errors and then restart with\
 0:23.18                "/usr/bin/make -f client.mk build"
 0:23.18 make[2]: *** [configure] Error 1
 0:23.18 make[1]: *** [/scratch/work/builds/mozilla-central/mozilla-central-11-11-01.13-56/mozilla/obj-x86_64-unknown-linux-gnu/Makefile] Error 2
 0:23.18 make: *** [build] Error 2
}

If I check in my objdir (obj-x86_64-unknown-linux-gnu), I definitely see a "config.status" file there.  I'm guessing we're failing to find it because we're looking in the wrong place, or something.

I'm on 64-bit Ubuntu 14.04, if that matters, with up-to-date mozilla-central.

Comment 1

[Daniel Holbert [:dholbert]]

If I run ./mach build a second time after hitting this, I get slightly different output:

{
 0:02.95 checking for posix_fadvise... (cached) yes
 0:02.95 checking for posix_fallocate... (cached) yes
 0:03.01 creating ./config.status
 0:03.46 Traceback (most recent call last):
 0:03.46   File "/scratch/work/builds/mozilla-central/mozilla-central-11-11-01.13-56/mozilla/build/subconfigure.py", line 354, in <module>
 0:03.46     sys.exit(main(sys.argv[1:]))
 0:03.46   File "/scratch/work/builds/mozilla-central/mozilla-central-11-11-01.13-56/mozilla/build/subconfigure.py", line 338, in main
 0:03.46     return run(CONFIGURE_DATA, args[0])
 0:03.46   File "/scratch/work/builds/mozilla-central/mozilla-central-11-11-01.13-56/mozilla/build/subconfigure.py", line 243, in run
 0:03.46     config_files, command_files = get_config_files(data)
 0:03.46   File "/scratch/work/builds/mozilla-central/mozilla-central-11-11-01.13-56/mozilla/build/subconfigure.py", line 141, in get_config_files
 0:03.46     stderr=subprocess.STDOUT).splitlines()
 0:03.46   File "/usr/lib/python2.7/subprocess.py", line 573, in check_output
 0:03.46     raise CalledProcessError(retcode, cmd, output=output)
 0:03.46 subprocess.CalledProcessError: Command '['/bin/sh', '-c', 'js/src/config.status --help']' returned non-zero exit status 127
 0:03.46 *** Fix above errors and then restart with\
 0:03.46                "/usr/bin/make -f client.mk build"
 0:03.46 make[2]: *** [configure] Error 1
 0:03.46 make[1]: *** [/scratch/work/builds/mozilla-central/mozilla-central-11-11-01.13-56/mozilla/obj-x86_64-unknown-linux-gnu/Makefile] Error 2
 0:03.46 make: *** [build] Error 2
}

Comment 2

[Daniel Holbert [:dholbert]]

Observation: This output from comment 1...
> 0:03.46 subprocess.CalledProcessError: Command '['/bin/sh', '-c', 'js/src/config.status --help']
... looks superficially like we're trying to run js/src/config.status as a shell script (with /bin/sh) when really it's a python script.

That seems bad, though it may not be the main underlying problem here.

Comment 3

[Daniel Holbert [:dholbert]]

(though, that file does have a #! line saying to run it with python. Maybe /bin/sh is smart enough to read that & invoke it... it probably is, so marking comment 2 as obsolete.)

Comment 4

[Daniel Holbert [:dholbert]]

UPDATE: This seems to be dependent on the path length.

In particular, I hit this issue with the following srcdir:
> /tmp/aaaaaaaaa/bbbbbbbbb/ccccccccc/ddddddddd/eeeeeeeee/fffffffff/123456789
...but I don't hit it if I drop a single character from the end -- i.e. this srcdir does not hit this error:
>/tmp/aaaaaaaaa/bbbbbbbbb/ccccccccc/ddddddddd/eeeeeeeee/fffffffff/12345678

Comment 5

[Daniel Holbert [:dholbert]]

Further update: The "without mozconfig" aspect of this bug was a red herring -- it turns out that the no-mozconfig condition initially *seemed* responsible because I was *close* to the threshold of triggering this bug, but I'd configured a shorter objdir in my normal mozconfig, and that was saving me. (and if I removed it & used the default objdir path, I'd run into to this bug.)

So, these STR should be more reliable & simpler:
 1. Create directory /tmp/aaaaaaaaa/bbbbbbbbb/ccccccccc/ddddddddd/eeeeeeeee/fffffffff/
 2. Create the following single-line mozconfig file, in any mozilla srcdir (without the leading "> "):
> mk_add_options MOZ_OBJDIR=/tmp/aaaaaaaaa/bbbbbbbbb/ccccccccc/ddddddddd/eeeeeeeee/fffffffff/123456789-obj-x86_64-unknown-linux-gnu

 3. Try to build. See if you get past the configuration stage.

This reproduces the ACTUAL RESULTS from comment 0 reliably for me.

Comment 6

[Daniel Holbert [:dholbert]]

Also, FWIW, the full path of $OBJDIR/js/src/config.status (which I think is the problem file, per comment 1) is 125 characters long.
i.e. this is 125 characters:
/tmp/aaaaaaaaa/bbbbbbbbb/ccccccccc/ddddddddd/eeeeeeeee/fffffffff/123456789-obj-x86_64-unknown-linux-gnu/js/src/config.status

If I reduce the objdir length by 1 (bringing this ^ path-length down to 124 characters), then we get past this step. I wonder if 124 characters is a hard limit that's set by some tool that we're using? That seems like a pretty short limit.