Hi Erik, On 01/02/15 14:50, Erik van Pienbroek wrote: > Jacek Caban schreef op vr 02-01-2015 om 10:46 [+0100]: >> On 01/01/15 18:30, Erik van Pienbroek wrote: >>> Apparently wine-gecko fails to build when these symbols are only >>> available with _WIN32_WINNT >= 0x0600. @Jacek: could this be a >>> wine-gecko bug? I've workaround'ed this issue in Fedora 20 using >>> attached 0021-Lower-_WIN32_WINNT-requirements-for-Un-RegisterPower.patch >>> but my guess is this is not the right fix as I think wine-gecko should >>> set _WIN32_WINNT to 0x0600 while compiling the file >>> hal/windows/WindowsBattery.cpp. >> I don't see the problem here. I remember fixing some version handling >> version macros for similar reason. Maybe 4d7b86c46 would help. > Hi Jacek, > > I tried building wine-gecko without the > 0021-Lower-_WIN32_WINNT-requirements-for-Un-RegisterPower.patch > workaround which I mentioned in my initial post and replaced it with a > cherry-pick of commit 4d7b86c46. Unfortunately this combination fails > with: > > /home/erik/fedora/mingw-wine-gecko/mingw-wine-gecko-2.34/wine-mozilla-2.34/hal/windows/WindowsBattery.cpp:24:17: > error: 'RegisterPowerSettingNotification' was not declared in this scope > static decltype(RegisterPowerSettingNotification)* > sRegisterPowerSettingNotification = nullptr;
I gave it another thought from another perspective. We don't need those notifications for wine-gecko anyway, so I will disable related code. I will let you know when I commit that. >>> Would it be possible to backport all the commits mentioned in this mail >>> to the mingw-w64 v3.x branch and release a mingw-w64 v3.4.0 soon so >>> others can benefit from these changes as well? >> I'm not really involved in stable branches. That's quite a few patches >> to cherry-pick, so it's not something an usual stable branch should >> take. On the other hand, if stable releases are so rare, maybe existing >> stable releases should take more cherry-picks. > I agree that the amount of changes is quite large and that is is > questionable whether this really is material for the v3.x branch..but on > the other hand it is the only realistic option we have if we want to be > able to get the latest wine working in Fedora 20. > >> Maybe we could find some long term solution. How did you deal with >> mingw-w64 requirements in the past, when wine-gecko was released every >> three months? How hard would it be to use some version off the master >> branch just for wine-gecko? > In the mailing list thread "RFE: New stable release" I just tried to > explain how we do things in Fedora (it's a bit off-topic for this > specific thread). In general I personally agree that we should release more, but I will reply in another thread to that. I don't want this to be mixed with wine-gecko releases discussion. Jacek ------------------------------------------------------------------------------ Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
