This repository was archived by the owner on Nov 12, 2022. It is now read-only.
This repository was archived by the owner on Nov 12, 2022. It is now read-only.
Failure in Windows and MacOS CI #559
Open
Description
Currently, MacOS CI is failing. It seems to be due to an issue in configure.py
but I have no idea what it could be.
Windows CI is also failing, which is very weird given it compiles just fine for me locally.
https://github.com/Redfire75369/rust-mozjs/runs/8271056707
Activity
[-]Failure in MacOS CI[/-][+]Failure in Windows and MacOS CI[/+]jdm commentedon Sep 11, 2022
Ah, this is the same issue as servo/servo#28911 and needs to be addressed like servo/servo#28960.
sagudev commentedon Sep 11, 2022
I believe SM update might solve this issues.
jdm commentedon Sep 11, 2022
The windows errors look a bit like we may need an LLVM upgrade.
redfire75369 commentedon Sep 12, 2022
I see upgrading LLVM fixed the windows builds, but I'm just wondering how it requires an llvm update even though the code didn't change.
How did the currently used llvm version start to not work, if the code is just the same?
jdm commentedon Sep 12, 2022
Because the MSVC installation in the CI environment is updated regularly, and those upgrades can include a new version of clang. However using bindgen in the build requires a full LLVM installation, which MSVC doesn't include, and so the version of LLVM that we install needs to remain in sync with the clang version that is present in MSVC.
jdm commentedon Sep 12, 2022
I think you're right. It may be a similar problem to https://bugzilla.mozilla.org/show_bug.cgi?id=1657717
redfire75369 commentedon Sep 15, 2022
On another note, thanks for the information about MSVC in the CI.
It helped me realise why spiderfire's CI was failing, I didn't peg the version so it just went to LLVM 15. 😅
It seems the Windows CI environment has LLVM already, would it be possible to use that instead of installing it with scoop?
(https://github.com/actions/runner-images/blob/main/images/win/Windows2022-Readme.md)
yvt commentedon Sep 19, 2022
The symptom is similar, but I think it's a separate issue. I was able to reproduce the issue locally and found that the whole
_virtualenvs/init_py3/bin
directory (not just thebin/python
file as indicated by https://bugzilla.mozilla.org/show_bug.cgi?id=1657717#c1) was missing. The Python binaries were instead placed in a different directory,_virtualenvs/init_py3/opt/homebrew/bin
:It appears to be the combination of the following factors that caused this issue:
sysconfig
to return Homebrew-specific system paths, e.g.,/opt/homebrew/bin
. (The Python 3.9 formula doesn't do this.)mozjs_sys
) locates installation paths by callingsysconfig.get_path(i, expand=False)
. (I'm speculating that virtualenv contents are laid out according to this.)venv
scheme from bpo-45413: Define "posix_venv", "nt_venv" and "venv" sysconfig installation schemes python/cpython#31034 (officially added in Python 3.11). Tools like virtualenv must pass this scheme tosysconfig.get_path
to get the correct paths, e.g.,{base}/bin
, for virtual environments.venv
scheme was absent until virtualenv 20.10.0 (where Favor the "venv" sysconfig install scheme over the default and distutils scheme pypa/virtualenv#2209 was merged), so virtualenv 20.2.2 happily lays out virtualenv contents according to the Homebrew-specific installation paths, breaking our tools.Edit: Found the upstream issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1766497
redfire75369 commentedon Sep 19, 2022
From a first read through, I think this would require a patch to update
virtualenv
to 20.10.0?At least until an update to SM97 or further.
I'm not sure if
mozjs/python/mozbuild/mozbuild/virtualenv.py
needs to be patched, butmozjs/third_party/python/virtualenv/
probably does.yvt commentedon Sep 20, 2022
Looks like they attempted to bump
virtualenv
to 20.15.0 in https://hg.mozilla.org/mozilla-central/rev/450e42238ace99a6e8ff5fc167b44c6a734e8e6d, although it was reverted later due to CI regressions. I think we can just incorporate this patch until a reliable solution is implemented in upstream.Meanwhile, I think I've found the right upstream issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1766497
Alternatively, we could temporarily downgrade Python to 3.9 in the CI environment.
python3
topython3.9
on Homebrew #561Auto merge of #561 - yvt:patch/ci-chore-python3p9, r=jdm