https://bugs.winehq.org/show_bug.cgi?id=51918
Bug ID: 51918 Summary: wine-gecko 2.47.2 fails to build on host systems with python 3.10 Product: Wine-gecko Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-gecko-unknown Assignee: jacek@codeweavers.com Reporter: patrick+winehq.org@laimbock.com Distribution: ---
Created attachment 70873 --> https://bugs.winehq.org/attachment.cgi?id=70873 Python-3.10 fixes for wine-gecko 2.47.2
Successor of https://bugs.winehq.org/show_bug.cgi?id=49126
Another round of fixes are needed so that wine-gecko 2.47.2 builds with python-3.10 (present in e.g. the upcoming Fedora 35)
Attached is a patch with some fixes until I got stuck due to a limited amount of pyFoo. I'll be happy to test a tree with fixes.
Fedora bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1987713
https://bugs.winehq.org/show_bug.cgi?id=51918
--- Comment #1 from Jacek Caban jacek@codeweavers.com --- Most of the patch looks good and should not break older Python, so I pushed it, thanks.
virtualenv.py looks suspicious through. What's the problem that it's trying to fix?
https://bugs.winehq.org/show_bug.cgi?id=51918
--- Comment #2 from Rafał Mużyło galtgendo@o2.pl --- ...unless you're referring to that get_default_scheme change, my very underdeveloped python skills tell me it's pretty obvious: sys.version[:3] -> sys.version[:4] is to prevent '3.10' becoming '3.1'.
Yes, that would break with older pythons, but fixing it in a compatible way (like by using sys.version_info) would make the code more complicated. So, you know, tradeoffs.
https://bugs.winehq.org/show_bug.cgi?id=51918
--- Comment #3 from Patrick patrick+winehq.org@laimbock.com --- (In reply to Jacek Caban from comment #1)
Most of the patch looks good and should not break older Python, so I pushed it, thanks.
virtualenv.py looks suspicious through. What's the problem that it's trying to fix?
Thanks Jacek. As Rafał commented, the sys.version[:3] -> sys.version[:4] change in virtualenv.py was to also handle python 3.10 (and to prevent it to be detected as python 3.1).
https://bugs.winehq.org/show_bug.cgi?id=51918
--- Comment #4 from Patrick patrick+winehq.org@laimbock.com --- Created attachment 71046 --> https://bugs.winehq.org/attachment.cgi?id=71046 More py3.10 fixes
More py3.10 fixes in virtualenv.py
Replaced some tabs with spaces.
- if sysconfig._get_default_scheme() == 'posix_local': + if sysconfig.get_default_scheme() == 'posix_local':
And a fix for an assertion due to an incorrect version test: sys.version[:3] gives 3.1 with python 3.10.
- assert os.path.basename(lib_dir) == 'python%s' % sys.version[:3], ( + assert os.path.basename(lib_dir) == 'python%s.%s' % (sys.version_info[0], sys.version_info[1]), (
https://bugs.winehq.org/show_bug.cgi?id=51918
--- Comment #5 from Patrick patrick+winehq.org@laimbock.com --- Please ignore this fix:
- if sysconfig._get_default_scheme() == 'posix_local': + if sysconfig.get_default_scheme() == 'posix_local':
Although the py3.10 docs said that _get_default_scheme was renamed to get_default_scheme, that was not the case on the py.301 on Fedora 35.
https://bugs.winehq.org/show_bug.cgi?id=51918
--- Comment #6 from Jacek Caban jacek@codeweavers.com --- With _get_default_scheme part reverted the patch works with python 3.9 and looks good to me. Is it enough for python 3.10?
https://bugs.winehq.org/show_bug.cgi?id=51918
--- Comment #7 from Patrick patrick+winehq.org@laimbock.com --- Created attachment 71164 --> https://bugs.winehq.org/attachment.cgi?id=71164 Fix assert due to detecting python 3.10 as python 3.1
https://bugs.winehq.org/show_bug.cgi?id=51918
--- Comment #8 from Patrick patrick+winehq.org@laimbock.com --- The "Fix assert due to detecting python 3.10 as python 3.1" patch seems to be missing. I still have more errors so more to come.
https://bugs.winehq.org/show_bug.cgi?id=51918
--- Comment #9 from Patrick patrick+winehq.org@laimbock.com --- Created attachment 71165 --> https://bugs.winehq.org/attachment.cgi?id=71165 Build failure with HEAD plus the assert fix
Attached log is the build failure from HEAD with the assert fix on Fedora 35 with Python 3.10 and mingw{32,64}-gcc{-c++}-11.2.1-3.fc35.x86_64
https://bugs.winehq.org/show_bug.cgi?id=51918
--- Comment #10 from Patrick patrick+winehq.org@laimbock.com --- See also: https://bugzilla.redhat.com/show_bug.cgi?id=1987713
Additional fixes required to be able to build with python 3.10:
1) replace virtualenv with the one here that's compatible with py3.10: https://github.com/pypa/virtualenv/tree/legacy
2) additional py3.10 compatibility patch (I'll add that next)
But the build still fails:
With make -j1 it fails with 'storage size of mreq isn't known' So the bug from https://bugs.winehq.org/show_bug.cgi?id=52085
With make it also fails. Copr build here: https://copr.fedorainfracloud.org/coprs/patrickl/mingw-wine-gecko/build/3163...
And the log files here: https://download.copr.fedorainfracloud.org/results/patrickl/mingw-wine-gecko...
Any ideas?
https://bugs.winehq.org/show_bug.cgi?id=51918
--- Comment #11 from Patrick patrick+winehq.org@laimbock.com --- Created attachment 71632 --> https://bugs.winehq.org/attachment.cgi?id=71632 Py3.10 fixes needed after the virtualenv -16.7.11 replacement
Small patch with some py3.10 fixes needed after replacing virtualenv with the one from the lgacy branch so the build progresses.
https://bugs.winehq.org/show_bug.cgi?id=51918
Michael Cronenworth mike@cchtml.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mike@cchtml.com
https://bugs.winehq.org/show_bug.cgi?id=51918
Jacek Caban jacek@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
--- Comment #12 from Jacek Caban jacek@codeweavers.com --- I tested your fixes and they are enough for me to get it building with python 3.10.2, both with GCC and Clang-based toolchains. Thanks! I will get them committed after a bit more testing.
I looked at your logs for the remaining problem, but I don't see why it fails, unfortunately. It looks like make just silently fails.
https://bugs.winehq.org/show_bug.cgi?id=51918
--- Comment #13 from Michael Cronenworth mike@cchtml.com --- Yes, the fixes work under Fedora, too. Thanks, Patrick.
It's unfortunate that the jobserver functionality is not working. Any ideas on what is breaking it?
https://bugs.winehq.org/show_bug.cgi?id=51918
--- Comment #14 from Patrick patrick+winehq.org@laimbock.com --- (In reply to Michael Cronenworth from comment #13)
Yes, the fixes work under Fedora, too. Thanks, Patrick.
Glad to be of help.
It's unfortunate that the jobserver functionality is not working. Any ideas on what is breaking it?
Limited knowledge here but based on yesterday's jobserver bugfix in OpenLDAP and a quick look on SO & in the code, there are a lot of hardcoded instances of 'make -jX'. AFAICT those should be replaced with $(MAKE).
And there's:
$ grep -R '$MAKEOPTS' . ./wine/make_package: echo "mk_add_options MOZ_MAKE_FLAGS="$MAKEOPTS""
$config_file
./wine/make_package: MOZCONFIG=$build_dir/mozconfig make $MAKEOPTS -C $build_dir ./wine/make_package: MOZCONFIG=$build_dir/mozconfig make $MAKEOPTS -C $build_dir/browser/installer