Dan Kegel wrote:
On Mon, Aug 10, 2009 at 6:50 AM, Jacek Caban<[email protected]> wrote:
While I agree with this arguments, I think Wine would benefit more from
compiling using MinGW in case of Firefox. It would test code of Wine Gecko
package, which would be great. Obviously MSVC compilation would also test
this code, but the nearer build config would be, the better. There are
instructions about how to get it compiled on the Wiki:
http://wiki.winehq.org/BuildingWineGecko
Using wine/mozconfig-browser from Wine Gecko source would be a good start
(it builds Firefox debug version). Unfortunately this compilation is quite
complicated. I will use a chance to write about it here.
Thanks, I'll look into it. I'm still going to do the MSVC version
first, since I already have one mingw build, but I agree
Wine would benefit from being able to self-host the build
of its own Gecko component.
I should write it more precisely, sorry. We already use Linux MinGW
version, so there is nothing to host. The point is that it should build
using Linux MinGW (which is broken in mainstream Mozilla) and run
regression test in Wine.
If anyone else wants to
jump in and do the mingw version, that'd be great.
- MinGW importlibs and includes are not good enough.
And worse, their developers don't seem to care. My bug report had no
response and AFAIK I'm not allowed to send them a patch:
http://sourceforge.net/tracker/?func=detail&atid=102435&aid=2824763&group_id=2435
so I didn't bother to file another bug reports.
IMHO it's still worth filing a few more bugs even if there's no response.
It helps document the problem for later.
Maybe we can do that once we have an automated
script to reproduce.
It's kind of documented. All broken libs and includes are in wine/lib
and wine/include directory of Wine Gecko source, so it's easy to find
what's broken. Also if we could use Wine instead of MinGW w32api, we'd
be able to produce fixes faster and we'd have a nice test for our headers.
Thanks,
Jacek
