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; > > 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). Unfortunately it isn't possible to use a custom version of mingw-w64 specifically to get wine-gecko built on older Fedora releases. It's basically all or nothing: if we update mingw-w64 in a Fedora branch then all other mingw packages and all mingw users are forced to use it. In the past we did also have issues with getting wine-gecko built but these were pretty minor compared to the one we're having now with wine-gecko 2.34. These minor issues could be pretty easily be resolved with minor changes in either mingw-w64 or wine-gecko. Regards, Erik ------------------------------------------------------------------------------ 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
