1739129 - _get_clang_tools always erase and untar tooltool files/

Status: RESOLVED WONTFIX

(Firefox Build System :: Mach Core, defect, P5)

Description

[Nicolas B. Pierron [:nbp — off until 29-09]]

So far tooltool pre-built binaries are unable to work on my system and cause the following errors:

exec: /home/nicolas/mozilla/wksp-4/mach -v clang-format --path js/src/frontend/
 0:04.50 Setting up artifact clang-tidy.tar.zst
 0:04.50 Using artifact from local cache: /home/nicolas/mozilla/_build/js/bb0a2f9701fb7/x64/clang12/pro/.mozbuild/toolchains/84718d518586c898-clang-tidy.tar.zst
 0:04.65 untarring "/home/nicolas/mozilla/_build/js/bb0a2f9701fb7/x64/clang12/pro/.mozbuild/clang-tools/clang-tidy.tar.zst"
Error running mach:

    ['-v', 'clang-format', '--path', 'js/src/frontend/']

The error occurred in code that was called by the mach command. This is either
a bug in the called code itself or in the way that mach is calling it.
You can invoke |./mach busted| to check if this issue is already on file. If it
isn't, please use |./mach busted file clang-format| to report it. If |./mach busted| is
misbehaving, you can also inspect the dependencies of bug 1543241.

If filing a bug, please include the full output of mach, including this error
message.

The details of the failure are as follows:

FileNotFoundError: [Errno 2] No such file or directory: '/home/nicolas/mozilla/_build/js/bb0a2f9701fb7/x64/clang12/pro/.mozbuild/clang-tools/clang-tidy/bin/clang-format': '/home/nicolas/mozilla/_build/js/bb0a2f9701fb7/x64/clang12/pro/.mozbuild/clang-tools/clang-tidy/bin/clang-format'

  File "/home/nicolas/mozilla/wksp-4/python/mozbuild/mozbuild/code_analysis/mach_commands.py", line 1228, in clang_format
    if not _is_version_eligible(command_context, clang_paths):
  File "/home/nicolas/mozilla/wksp-4/python/mozbuild/mozbuild/code_analysis/mach_commands.py", line 500, in _is_version_eligible
    current_version = _get_current_version(command_context, clang_paths)
  File "/home/nicolas/mozilla/wksp-4/python/mozbuild/mozbuild/code_analysis/mach_commands.py", line 470, in _get_current_version
    subprocess.check_output(cmd, stderr=subprocess.STDOUT)
  File "/nix/store/045ddnya6q9mam8mahmbl8kr93kfgrpi-python3-3.6.14/lib/python3.6/subprocess.py", line 356, in check_output
    **kwargs).stdout
  File "/nix/store/045ddnya6q9mam8mahmbl8kr93kfgrpi-python3-3.6.14/lib/python3.6/subprocess.py", line 423, in run
    with Popen(*popenargs, **kwargs) as process:
  File "/nix/store/045ddnya6q9mam8mahmbl8kr93kfgrpi-python3-3.6.14/lib/python3.6/subprocess.py", line 729, in __init__
    restore_signals, start_new_session)
  File "/nix/store/045ddnya6q9mam8mahmbl8kr93kfgrpi-python3-3.6.14/lib/python3.6/subprocess.py", line 1364, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)

Ideally, one should be able to add hooks in mach to such that downloaded binaries could be patched to make the downloaded version work with non standard library locations,

Or the tooltool binaries should all be statically linked to prevent such issues.

In the mean time, the work-around I used in the past was to patch/replace the binaries with working one within .mozbuild directory. However, this implies that one should patch prior the next mach command is running. The fact that _get_clang_tools always unpack causes trouble as I am no longer capable of maintaining a patched version of the binary across commands.

Comment 1

[Mitchell Hentges [:mhentges] 🦀]

Hmm, my initial stance here is that the binaries should work more generally without needing to be patched after downloading, though I don't fully understand the use case here. Can you share some more details?

• Do you know where the /home/nicolas/mozilla/_build/js/bb0a2f9701fb7/x64/clang12/pro/ path is coming from?
• What does your patch do?
• Where do you store your binaries, if not in /home/nicolas/.mozbuild/ or /home/nicolas/mozilla/_build/js/bb0a2f9701fb7/x64/clang12/pro/.mozbuild/?

Comment 2

[Nicolas B. Pierron [:nbp — off until 29-09]]

Ok, I found the dirtiest work-around so far, which is more likely to break than anything else:

(stdbuf -oL -eL inotifywait -mre create --format '%w%f' $MOZBUILD_STATE_PATH |
     while read file; do
       if test $file = $MOZBUILD_STATE_PATH/clang-tools/clang-tidy/bin/run-clang-tidy ; then
         ;: # … patch the file here …
       fi
     done)&

This work-around will just replace the file when it is unpacked, and replace it with the patched version.

PS: This is likely faster to implement than a FUSE filesystem for $MOZBUILD_STATE_PATH

Comment 3

[Nicolas B. Pierron [:nbp — off until 29-09]]

(In reply to Mitchell Hentges [:mhentges] 🦀 from comment #1)

Hmm, my initial stance here is that the binaries should work more generally without needing to be patched after downloading, though I don't fully understand the use case here. Can you share some more details?

• Do you know where the /home/nicolas/mozilla/_build/js/bb0a2f9701fb7/x64/clang12/pro/ path is coming from?

This path is coming from a wrapper script which will generate the build directory based on the branch name, compiler, architecture, compilation-mode. This way I store all my builds in the _build directory which is a sibbling of all the source directories.

This makes things easier to compare different build, or different compilers, or even do some cross compilation for testing JIT backends.

• What does your patch do?

Before, running patchelf and updating the RUN_PATH of the binary to be able to find the libc.
Lately, simply replacing the bin directory by the one provided by Nixpkgs.

• Where do you store your binaries, if not in /home/nicolas/.mozbuild/ or /home/nicolas/mozilla/_build/js/bb0a2f9701fb7/x64/clang12/pro/.mozbuild/?

They are in /home/nicolas/mozilla/_build/js/bb0a2f9701fb7/x64/clang12/pro/.mozbuild/. The error message No such file or directory is miss leading as the file do exists, but the elf loader cannot find the library requested by the file.

Comment 4

[Mike Hommey [:glandium]]

I don't think we want to cater to Linux systems that don't have LSB compatibility. Firefox builds won't work either in such an environment.

Although, eventually, we'll be using clang-format and clang-tidy from the clang toolchain, so if you can get your bootstrapped clang to work, it will work just as well.