Qt Creator need to be rebuilt after Qt 6's every major upgrade
Closed this issue · 6 comments
Description / Steps to reproduce the issue
Qt Creator uses the private API of Qt 6, so it needs to be rebuilt after each Qt 6 upgrade.
Otherwise, if you run qtcreator it will fail because it unable to locate program entry point on dlls.
Also, our upstream, Arch Linux, is maintaining a list of packages that need to be rebuilt after Qt 6 upgrade. Some of them are also in MSYS2's repo, so we may reuse some part of this list.
At least, there are following packages need to be rebuilt:
Expected behavior
Rebuild, and Qt Creator works again.
Actual behavior
Unable to locate program entry point on dlls.
Verification
- I have verified that my MSYS2 is up-to-date before submitting the report (see https://www.msys2.org/docs/updating/)
Windows Version
MSYS_NT-10.0-26100
MINGW environments affected
- MINGW64
- MINGW32
- UCRT64
- CLANG64
- CLANGARM64
Are you willing to submit a PR?
No response
CI shows which packages need to be rebuilt https://github.com/msys2/MINGW-packages/actions/runs/11492344868/job/31996151285?pr=22280#step:3:444
pyside6 update is in queue. The other 3 are in a pull request now.
CI shows which packages need to be rebuilt https://github.com/msys2/MINGW-packages/actions/runs/11492344868/job/31996151285?pr=22280#step:3:444
pyside6 update is in queue. The other 3 are in a pull request now.
Sorry, I just noticed.
Is it possible for us to automate this rebuild? Arch Linux has tools specifically for this situation.
Which part need to be automated? CI is already showing which packages need to be rebuild. In the end, human touch is required to fix the build or runtime issue.
Which part need to be automated? CI is already showing which packages need to be rebuild. In the end, human touch is required to fix the build or runtime issue.
I mean to automatically issue a rebuild of these packages (additional manually maintained packages that need to be built) when Qt 6 is upgraded. The reason these packages need to be rebuilt is not soname changes (more like "runtime issue") so it seems that CI can't figure them out directly. This may help prevent maintainers from forgetting.
The reason these packages need to be rebuilt is not soname changes (more like "runtime issue")
Both file name changes and API changes are checked in CI, see https://github.com/jeremyd2019/package-grokker
The reason these packages need to be rebuilt is not soname changes (more like "runtime issue")
Both file name changes and API changes are checked in CI, see https://github.com/jeremyd2019/package-grokker
OK, thanks.