General discussion about mingw-w64 packages #94
Comments
|
If it doesn't take forever to build like paraview I can add them later. By the way, there is now a mirror under https://ftp.f3l.de/~martchus/. |
|
no, no, they're both small, but I use them often |
|
nice, should I prefer this mirror over your website ? is it faster ? |
|
My website is hosted via VDSL 50000. The mirror is hosted at Hetzer so it should be faster and more reliable. However, the mirror might be updated a little bit slower. |
|
The packages should be there. |
|
Thanks! I already tested the new mirror. |
|
rebuilt, +0.01 % ccache hit rate :-) |
|
hi @Martchus, would it be possible to add mingw-w64-mesa ? |
|
Sure, Mesa under Windows sounds like fun. Reminds me that I wanted to add a package for |
|
But may I ask for what you use this? |
|
The mingw-w64-mesa package misses the make dependency Considering the log this would actually build llvmpipe provided LLVM was found: So maybe I'll extend the package to get |
|
I've tried following the instructions: https://www.mesa3d.org/llvmpipe.html But I could never get it to use llvm: Because of https://gitlab.freedesktop.org/mesa/mesa/blob/mesa-19.0.3/scons/llvm.py#L68-72 Setting the Or is there something else we could do? |
|
Looks like we could do: But I get:
This does not happen if I don't set the We only have
But in a pinch I tried:
Some
So, anyway, we still need |
|
hi @teohhanhui, I worked around the g++-posix and zlib issues. Could you retry to build the updated mingw-w64-mesa now ? |
|
@xantares Thanks for looking into it. I think I would have come up with similar changes. I'm trying to rebuild now although there's likely an install missing in the |
|
There's no install, as it's not supported. Besides mesa headers will clash with mingw headers. Import libs are not provided either. I think it's fine to provide just the dll, as it's meant to be a drop-in override of the system dll. |
|
I thought this would produce a 2nd DLL called So it seems your changes were working. The only thing missing was increasing |
|
ok, zlib is pulled by mingw-llvm now, and I've updated to 19.0.3, so no need to bump. |
|
Makes sense. |
|
I could not test yet on a windows box, did you ? |
|
Of course not :-) It is ages ago since I've tested a Qt Quick application but if I do I'll give the software renderer a try. |
|
great! |
|
If I understand correctly, |
|
Oh, you pass |
|
For the |
|
zlib is needed by llvm, or at least they link to it. yes, it seems debian uses g++-posix suffix as they provide both posix and win32 threads flavors, we only use posix what makes the lib larger is that we statically link llvm libs |
|
@Martchus I don't know if you could help me with this, but when I try to build my project https://github.com/teohhanhui/paper-chess with The dynamic build works perfectly. Edit: Removing Do you have any idea why it was added in the first place? Is this related?
https://sourceforge.net/projects/mingw/files/MinGW/Extension/zlib/zlib-1.2.7-1/ Edit: And the result (from Dependency Walker profiling): I don't understand why lol... Perhaps I did something wrong when upgrading the |
|
Seems like the function has been introduced only in Windows 10 version 1607 (see https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-systemparametersinfofordpi). So If you're using a totally outdated version of Btw, I can also check the import libs for their symbols locally, e.g.: On this system the latest crt from testing is installed: (But I suppose the version from the normal repo should be recent enough as well.) |
|
Thank you for your fast response. You're absolutely right. My Thanks! |
|
Judging by |
|
jfyi, the version in the community repo just got updated and now contains |
|
I've just tried to make the switch from Qt5->6 cross-compiling a little tool for Windows when I ran into a weird issue. For some reason CMake seems to keeps adding a local When I try to use Qt6 the following -isystem paths get added -isystem /usr/x86_64-w64-mingw32/include/qt6/QtWidgets
-isystem /usr/x86_64-w64-mingw32/include/qt6
-isystem /usr/x86_64-w64-mingw32/include/qt6/QtCore
-isystem /usr/x86_64-w64-mingw32/lib/qt6/mkspecs/win32-g++
-isystem /usr/x86_64-w64-mingw32/include/qt6/QtGui
-isystem /usr/include when using Qt5 on the other hand -isystem /usr/x86_64-w64-mingw32/include/qt
-isystem /usr/x86_64-w64-mingw32/include/qt/QtWidgets
-isystem /usr/x86_64-w64-mingw32/include/qt/QtGui
-isystem /usr/x86_64-w64-mingw32/include/qt/QtCore
-isystem /usr/x86_64-w64-mingw32/lib/qt/mkspecs/win32-g++ Both times I simply pass Pardon me if this is unrelated to the actual package, I wasn't entirely sure if this is the right place to ask. /edit |
|
Has the By the way, I usually just check the CMake cache for any variables containing e.g. |
|
Note that our cmake wrapper has already |
|
Sadly yes. With
Makes no difference whether it's ON or OFF. |
|
So you're not using the toolchain file provided by You could use |
Honestly, I just didn't know about that... 😄 |
|
with the upgrade to mingw-gcc 12 some symbols were removed from libstdc++ and no longer work with gcc 11 libs: could these be rebuilt ?
I already bumped the build numbers |
|
Ok. I'll start these builds after my currently running builds have been concluded. I've also noticed that all static libs need to be rebuilt when LTO was enabled. (And it is therefore likely better to disable LTO at least for static libs in those packages.) |
|
thanks, edit: it was llvm, not mesa |
|
Btw, you can watch the build here: https://martchus.no-ip.biz/buildservice/#build-action-details-section?83 |
|
that is so cool! |
|
I found two more :
|
|
Those have been rebuilt as well. |
|
Updating mingw-w64-qt6-base from 6.3.0 to 6.3.1 fails on my system. CMake Warning at cmake/QtToolHelpers.cmake:142 (find_package):
Could not find a configuration file for package "Qt6CoreTools" that is
compatible with requested version "6.3.1".
The following configuration files were considered but not accepted:
/usr/lib/cmake/Qt6CoreTools/Qt6CoreToolsConfig.cmake, version: 6.3.0
Call Stack (most recent call first):
src/tools/moc/CMakeLists.txt:8 (qt_internal_add_tool)
CMake Error at cmake/QtToolHelpers.cmake:170 (message):
The tool "Qt6::moc" was not found in the Qt6CoreTools package. Package
found: 0
Call Stack (most recent call first):
src/tools/moc/CMakeLists.txt:8 (qt_internal_add_tool)
-- Configuring incomplete, errors occurred!
See also "/var/tmp/pamac-build-vinci/mingw-w64-qt6-base/src/build-i686-w64-mingw32/CMakeFiles/CMakeOutput.log".
See also "/var/tmp/pamac-build-vinci/mingw-w64-qt6-base/src/build-i686-w64-mingw32/CMakeFiles/CMakeError.log".
==> ERROR: A failure occurred in build().
Aborting...I've also tried to update mingw-w64-qt6-tools prior to that, but that doesn't work either. |
|
Please wait until the regular qt6-base package is updated to 6.3.1. It is currently in the official testing repo and will be moved to extra soon (when exactly is for official Arch devs to decide). I have already conducted builds of the mingw-64 and android Qt 6 packages against the official testing repo which works as well. (My builds are on my ownstuff-testing repo and will be moved to my ownstuff repo when official packages have been moved.) |
|
hi, could mingw-w64-ceres-solver be rebuilt ? It needs it since the glog upgrade (I already bumped it). |
|
Done |
|
thanks |
|
May ask you to add mingw-w64-gtksourceview5 and mingw-w64-libadwaita to your repository, please? MSYS2 packages: https://packages.msys2.org/base/mingw-w64-gtksourceview5 I also need mingw-w64-gtk4, but I already saw it here: https://aur.archlinux.org/packages/mingw-w64-gtk4 I hope I can use several repositories simultaneously (I'm not familiar with the way Arch package management works)... |
|
I'm currently adding gtk4 but the other packages needed to be added as AUR packages first. I recommend adding those packages yourself. You can add as many repos as you like, e.g. official ones, my repo and you own one on top of that. (Repos specified first in pacman.conf have precedence.) |
|
Unfortunately gtk4 pulled in many more packages. One of those packages is librsvg and it didn't build (see https://martchus.no-ip.biz/buildservice/#build-action-details-section?54). I assume I need to rebuild rust before so maybe I'll postpone adding gtk4 (because rust takes very long to compile). |
|
GTK4 is there now, including all its dependencies. Building rust didn't even take that long anymore. Maybe they've improved something in their build system or the Ryzen 9 5900X made the tremendous difference :-) |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
Since the stale bot wants to close the issue anyways, I'll move the discussion to #145. Let's see how well GitHub's discussion feature works but it seems to be made exactly for our use case here. |
would it be possible to add mingw-w64-ceres(depends on mingw-w64-google-glog) and mingw-w64-nlopt to ownstuff ?
The text was updated successfully, but these errors were encountered: