Open Bug 369591 (msvcwine) Opened 13 years ago Updated 2 years ago

Changes to build system to allow building from wine

Categories

(Firefox Build System :: General, enhancement)

x86
Linux
enhancement
Not set

Tracking

(Not tracked)

People

(Reporter: Mook, Unassigned)

References

(Depends on 2 open bugs)

Details

Attachments

(11 files, 2 obsolete files)

12.90 KB, patch
Details | Diff | Splinter Review
491 bytes, application/octet-stream
Details
8.22 KB, patch
Details | Diff | Splinter Review
1.22 KB, text/plain
Details
1.12 KB, text/plain
Details
10.00 KB, application/x-tar
Details
1.28 KB, application/octet-stream
Details
7.01 KB, patch
Details | Diff | Splinter Review
5.06 KB, patch
Details | Diff | Splinter Review
22.29 KB, patch
Details | Diff | Splinter Review
4.64 KB, patch
Details | Diff | Splinter Review
Mozilla can be made to build on Wine for Windows, using MSVC.  And putting the patches in bugzilla probably would outlast anywhere I can manage...

Yes, I'm probably crazy.

I'm building on OpenSuSE 10.2/Wine 0.9.29/MSVC 7.1/make 3.80.  The MSVC parts come from a Windows XP machine with it installed (properly).

Attaching a patch that sorta works on trunk - still some cleanup needed (nsIXULRuntime.OS is wrong at the very least), and needs a bit of hand holding for now.  Will get instructions later.  Diff against trunk ~2007-02-02

Also tested msys/msvc (MozillaBuild), cygwin/msvc, linux/gcc, linux/mingw to make sure I didn't break those builds :)
Status: NEW → ASSIGNED
Assignee: nobody → mook.moz+mozbz
Status: ASSIGNED → NEW
Comment on attachment 254287 [details] [diff] [review]
work in progress patch (cd mozilla; patch -p1 -i)

> ifeq ($(OS_TARGET), WINCE)
> OUTOPTION = -Fo# eol
> endif
> 
>+ifeq (,$(CROSS_COMPILE))
>+HOST_OUTOPTION = $(OUTOPTION)#eol
>+else
>+#TODO: cross compile from non-GCC hosts
>+HOST_OUTOPTION = -o #eol
>+endif
I'm wondering whether the WINCE target is trying to do something sneaky here, instead of being a real cross-compile target.

>+    if test -z "$CC"; then CC=cl.exe; fi
>+    if test -z "$CXX"; then CXX=cl.exe; fi
>+    if test -z "$CPP"; then CPP=cl.exe; fi
>+    if test -z "$LD"; then LD=link.exe; fi
>+    if test -z "$AS"; then AS=ml.exe; fi
>+    if test -z "$MIDL"; then MIDL=midl.exe; fi
I did't like the .exe extensions, it makes it harder for me to insert a script earlier in the path, but I haven't tried calling my script cygwin-wrapper ;-)

>+    AC_EXEEXT([.exe])
This works for me as just AC_EXEEXT

>+    HOST_AR=ar
>+    HOST_AR_FLAGS='cr $@'
I prefer not to make HOST_AR default at all (it currently defaults to '$(AR)') and I prefer to make that 'cr $@' the default of HOST_AR_FLAGS (currently '$(AR_FLAGS)').

> if test -n "$_WIN32_MSVC"; then
>     SKIP_PATH_CHECKS=1
>-    SKIP_COMPILER_CHECKS=1
>+#    SKIP_COMPILER_CHECKS=1
>     SKIP_LIBRARY_CHECKS=1
>+    AC_EXEEXT([.exe'])
AC_EXEEXT again; also is it possible to do the path and library checks for _WIN32_MSVC too?

I also had to move cross_compiling=yes from the start of the if test "$target" != "$host"; then to just before the else because otherwise the compiler test resets the cross_compiling flag (and I think Mac x86/ppc cross-compile has a hack to work around this bug).
(In reply to comment #1)
Thanks for the review comments :)
> I'm wondering whether the WINCE target is trying to do something sneaky here,
> instead of being a real cross-compile target.
Hmm, I'm not quite sure yet...

> I did't like the .exe extensions, it makes it harder for me to insert a script
> earlier in the path, but I haven't tried calling my script cygwin-wrapper ;-)
I guess using wrapper scripts might actually be better... Since configure itself doesn't use cygwin-wrapper, I still need to use binfmt_misc to get Linux to run the exe files with wine.  And that should mean I won't need to have a HOST_CYGWIN_WRAPPER set...

Will test in a moment.  I hope this won't get me the reverse of the "cygwin link is not msvc link" problem :)

> 
> >+    AC_EXEEXT([.exe])
> This works for me as just AC_EXEEXT
Okay, changing (and below too)

> 
> >+    HOST_AR=ar
> >+    HOST_AR_FLAGS='cr $@'
> I prefer not to make HOST_AR default at all (it currently defaults to '$(AR)')
> and I prefer to make that 'cr $@' the default of HOST_AR_FLAGS (currently
> '$(AR_FLAGS)').
Yeah, that would have been better, but I considered that scary change.  Especially since I don't have access to stranger configurations...

> 
> > if test -n "$_WIN32_MSVC"; then
> >     SKIP_PATH_CHECKS=1
> >-    SKIP_COMPILER_CHECKS=1
> >+#    SKIP_COMPILER_CHECKS=1
> >     SKIP_LIBRARY_CHECKS=1
> >+    AC_EXEEXT([.exe'])
> AC_EXEEXT again; also is it possible to do the path and library checks for
> _WIN32_MSVC too?
Note to self: TODO :)

> 
> I also had to move cross_compiling=yes from the start of the if test "$target"
> != "$host"; then to just before the else because otherwise the compiler test
> resets the cross_compiling flag (and I think Mac x86/ppc cross-compile has a
> hack to work around this bug).
> 
Oh, I thought that was on purpose!  That's why I kept on having to turn binfmt_misc on and off when using mingw-gcc vs wine-msvc...

Unrelated: next patch will actually be able to use bugzilla's patch viewer, and -p0 :)  Sadly I still don't know how to get more than 3 lines of context...
updated to review comments:
- changes so I /think/ WinCE cross-compile on MSVC host would work, but I'm not sure and I have no tools to test with.
- removed the .exe stuff, and the cygwin-wrapper stuff.  Neil is right, just using wrapper scripts around every executable (cl, lib, link, midl, ml, and rc) is better.  So I changed rc.exe to rc while I'm at it too
- AC_EXEEXT([.exe]) -> AC_EXEEXT (x2)
- removed the HOST_AR defaults.
- didn't dare touch the path/lib checks.  The lib checks especially look like they'd fail...
- didn't touch cross_compiling=yes yet.
Attachment #254287 - Attachment is obsolete: true
Attached file perl wrapper I'm using
For reference, here's the perl wrapper I'm using - place in MSVC71 bin directory and symlink as "cl", "lib", etc.

I expect to need to run an extra "ulimit -Ss 8192" in the case of RC (see winehq-bug 7140)
Note: excluding security, because I haven't got that far yet.
Additionally each of the MSVC utilities has its own subwrapper
e.g. /usr/local/bin/cl is the following script:
!#/bin/sh
. interix-wrapper cl.exe "$@"
Included is a little script called "winebox" (mostly borrowed from Neil's code) that is set up kind of like busybox.  The necessary VC tools (cl, link et al.) are symlinked to winebox, and winebox converts UNIX-style absolute pathnames in the args into windows style.  Then it exec()s the command under WINE.  winebox assumes that your WINE drive lives under /home somewhere.

Also included is a grep wrapper script that understands '\r\n' to match $.  This wrapper is necessary to make AC_TRY_CPP() work on my machine.

I'm going to write up instructions on MDC for setting all this up; it takes some work under MSVC9.  Maybe 7.1 works out of the box?
Assignee: mook.moz+mozbz → jones.chris.g
I haven't got DEBUG builds working yet.  Note that this mozconfig disables the installer; it requires makensis to be set up, and I just don't care enough.
The majority of this patch is an amalgamation of Mook's and Neil's older patches, un-bitrotted.  Thanks guys!

I can do OPT clobbers in about 23 mins. now without any tweaking of -j and so forth, which is about twice as fast as a win7 VM on the same machine, and about 3x faster than native XP on an older dual-core laptop.

I'm pretty sure the changes don't affect wince.  Kicking off a tryserver run to be sure.
Attachment #424743 - Flags: review?(ted.mielczarek)
Comment on attachment 424743 [details] [diff] [review]
Various build and configure hacks to support windows cross-compiles.

This is burning Wince, Winmo, and OS X on try.  Needs some more fiddling.
Attachment #424743 - Flags: review?(ted.mielczarek)
Passes tryserver now.  Split up per Ted's request.
Attachment #424743 - Attachment is obsolete: true
Attachment #424909 - Flags: review?(ted.mielczarek)
Note: the |LINK= $(LINK_DLL) ...| changes in security/coreconf/rules.mk are reasonable fixes (better would be not using "LINK" at all, but Neil tells me this change was already shot down).  That said, if there's pushback on taking those changes, the deficiency can be worked around by a |link.exe| wrapper script.
Attachment #424912 - Flags: review?(ted.mielczarek)
Comment on attachment 424912 [details] [diff] [review]
NSS support for Windows cross-compiles.

I'm not an NSS peer, I can't review this. Sorry, I think when you asked about rules.mk I thought you meant config/rules.mk in the Mozilla build system.
Attachment #424912 - Flags: review?(ted.mielczarek)
FWIW, my review queue is a bit backed up. I'm assuming you're not blocked on anything with these patches, so I'll get to them at some point when I clear out my queue.
Comment on attachment 424909 [details] [diff] [review]
Gecko support for Windows cross-compiles.

Pawning off reviews on Mitch.
Attachment #424909 - Flags: review?(ted.mielczarek) → review?(mitchell.field)
Attachment #424910 - Flags: review?(ted.mielczarek) → review?(mitchell.field)
Attachment #424911 - Flags: review?(ted.mielczarek) → review?(mitchell.field)
Chris said on IRC that he doesn't have time to refresh these patches. Cancelling reviews.
Attachment #424909 - Flags: review?(mitchell.field)
Attachment #424910 - Flags: review?(mitchell.field)
Attachment #424911 - Flags: review?(mitchell.field)
Assignee: jones.chris.g → nobody
Alias: msvcwine
Depends on: 1122785
Depends on: 1122796
FWIW I'm looking into doing this with MSVC2013.
Depends on: 1122930
Depends on: 1122931
Depends on: 1123017
Depends on: 1124906
Hi all,

I'm working on Cygwin/MSYS2 support on Wine, I'm not sure if Cygwin is required for building Firefox, but if anyone is interesting please have a look at: https://github.com/fracting/wine-fracting/wiki/MSYS2-on-Wine

MSVC support is also on my todo list, but it is a bit longer for me. Hopefully we can share information and work together, best regards.
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.