890877 - "No such file or directory" build failure with Python stack trace after "Installing pip...............done"

Status: RESOLVED INVALID

(Thunderbird :: Untriaged, defect)

Description

[Andrew Buehler]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130626 Firefox/17.0 Iceweasel/17.0.7 (Nightly/Aurora)
Build ID: 20130626003702

Steps to reproduce:

I'm attempting to build Thunderbird on 64-bit Debian testing, with i386 enabled in multiarch.

I followed the directions in the MozDev article on a "Simple Thunderbird build" (including cloning comm-central and pulling other code via client.py), created a .mozconfig file containing only
  mk_add_options MOZ_MAKE_FLAGS=-j11
in order to intentionally leave one hardware thread free, and ran
  mozilla/mach build
as directed in that article.


Actual results:

The build failed with the following output:

========
32:16.09 /home/wanderer/text/src/mercurial/mozilla/comm-central-clean/mail/test/mozmill/runtest.py /home/wanderer/text/src/mercurial/mozilla/comm-central-clean/mail/test/mozmill/runtestlist.py /home/wanderer/text/src/mercurial/mozilla/comm-central-clean/mail/test/mozmill/mozmilltests.list automation.py /home/wanderer/text/src/mercurial/mozilla/comm-central-clean/mozilla/build/automationutils.py
32:16.78 Using real prefix '/usr'
32:16.78 New python executable in /home/wanderer/text/src/mercurial/mozilla/comm-central-clean/obj-x86_64-unknown-linux-gnu/mozilla/_tests/mozmill-virtualenv/bin/python
32:16.88 Installing setuptools............done.
32:17.20 Installing pip...............done.
32:17.21 Python: 2.7.5+ (default, Jun  2 2013, 13:26:34)
32:17.21 [GCC 4.7.3]
32:17.21 Traceback (most recent call last):
32:17.21   File "../../../mozilla/_tests/mozmill/resources/installmozmill.py", line 94, in <module>
32:17.21     main()
32:17.22   File "../../../mozilla/_tests/mozmill/resources/installmozmill.py", line 88, in main
32:17.22     returncode = call([pip, 'install'] + [os.path.abspath(package) for package in packages], env=env)
32:17.22   File "/usr/lib/python2.7/subprocess.py", line 524, in call
32:17.22     return Popen(*popenargs, **kwargs).wait()
32:17.22   File "/usr/lib/python2.7/subprocess.py", line 711, in __init__
32:17.22     errread, errwrite)
32:17.22   File "/usr/lib/python2.7/subprocess.py", line 1308, in _execute_child
32:17.22     raise child_exception
32:17.22 OSError: [Errno 2] No such file or directory
32:17.22 make[6]: *** [mozmill-virtualenv] Error 1
32:17.22 make[5]: *** [libs] Error 2
32:17.22 make[4]: *** [libs_tier_app] Error 2
32:17.22 make[3]: *** [tier_app] Error 2
32:17.22 make[2]: *** [default] Error 2
32:17.22 make[1]: *** [default] Error 2
32:17.22 make: *** [build] Error 2
32:17.22 903 compiler warnings present.
========

I've tried everything I know how (and a few things I didn't know how to do before), and have not managed to identify what file or directory it's unsuccessfully trying to access.

The same build (from a verbatim copy of the same tree) in a non-multiarch chroot, either 32-bit or 64-bit, completes with no more issues than the cosmetic "Exception: Binary expected at /src/mozilla/comm-central-clean/obj-...../dist/bin/thunderbird does not exist." error.


Expected results:

The build should have completed successfully.

The only thing I've found online reporting what look like similar error messages is bug 869609, which seems to have been a different problem; the fix from that bug seems to already be present in the tree I'm using. It still seems worth mentioning, since as in that bug, this is happening on a multiarch-enabled Debian.

Comment 1

[Andrew Buehler]

After discussion with jcranmer on IRC, it has been determined that this is not a bug in Thunderbird, or at most a very minor one which will not affect most build environments.

Under Linux, by default, the maximum length of a shebang line (#!) in an executable script is 127 characters; this limit is set in the kernel, at compile time. The shebang line for the Python scripts in the virtualenv directories under the objdir points to a Python executable located inside that virtualenv directory. In my build environment, for one of those directories, this shebang line comes to 129 characters (including the #! itself).

With the default name of an objdir in my environment, the relative path to that executable, counting from the first letter of the name of the objdir, is already 65 characters long; if you add 'comm-central/' on the beginning, that being the name of a default Mercurial checkout directory, that increases to 79. It could be argued that it's unreasonable for Mozilla to take up nearly two-thirds of the available path limit just within its own hierarchy, but it doesn't seem to be terribly so, because plainly this is not a problem for most people in practice.

This problem can be avoided by simply moving the source tree to a different location, whose path is short enough for the shebang to fall within the length limit; in my case, I should only need to reduce the total path length by 2 characters.

If someone has a situation where they can't (practically) move the source tree, there is still another workaround, though it requires root access: bind-mount the source tree to a directory which is under a shorter path. E.g., 'mkdir /shorter/path/ ; mount --bind /really/long/path/to/comm-central/ /shorter/path/'. Unfortunately, simply symlinking to the directory will not work, since virtualenv is "smart" enough to resolve the real pathnames rather than the symlinked ones.

Given that this failure does not originate within Thunderbird (or Mozilla) itself, and that it does not affect the large majority of people, and that the possible change to fix it (reducing the length of the build-tree-internal portion of the shebang path) would A: only make it less prominent rather than eliminating it entirely and B: almost certainly involve more trouble than having it 'fixed' would avoid, I am closing this bug as invalid.