#1 Building Firefox with 64-bit MinGW

[Mook]

NightStrike somehow got me into trying to cross-compile Mozilla Firefox on a Linux-i686 host.

Yes, I'm crazy.

I'm going to be using this to track problems hit; note that it is quite possible that issues noted may be a problem elsewhere (i.e. not everything will need to be fixed here). In particular, I expect lots of problems on the Mozilla side :)

Known issues so far:
- Need MinGW x86_64 libIDL.
- Temporarily building --disable-plugins --disable-oji

[Mook]

Logged In: YES
user_id=2055712
Originator: YES

In /x86_64-pc-mingw32/lib, I needed to add these symlinks:
libwinsock.a -> libmswsock.a
libwsock32.a -> libws2_32.a

(Again, this might be a Mozilla thing. It's a pretty old code base, so I wouldn't be surprised if this was using some ancient library name).

[Mook]

x86_64-pc-mingw32-g++ -c -O1 nsCipherInfo.ii

[Mook]

Logged In: YES
user_id=2055712
Originator: YES

Attached file causes a ICE when compiled with -O1, -O2, or -O3; it seems to be okay with -O0 and -Os.
x86_64-pc-mingw32-g++ -c -O3 nsCipherInfo.ii
x86_64-pc-mingw32-g++ (GCC) 4.4.0 20080404 (experimental)

File Added: nsCipherInfo.ii.bz2

[Mook]

Logged In: YES
user_id=2055712
Originator: YES

x86_64-pc-mingw32-g++ -mno-cygwin -shared -o gkwidget.dll nsWinWidgetFactory.o widget.res -Wl,--whole-archive ../windows/libwidg
et_windows.a ../xpwidgets/libxpwidgets_s.a -Wl,--no-whole-archive -L../../../dist/bin -L../../../dist/lib -lgkgfx -lthebes -L../../../dist/lib -lxpcom -lxpcom_core -L../../../dist/bin -L../../../dist/lib -lnspr4 -lplc4 -lplds4 ../../../dist/lib/libunicharutil_s.a -L../../../dist/bin -lmozlcms -lm -lgdi32 -lwinmm -lwsock32 -luuid -lole32 -loleaut32 -lwinspool -lcomctl32 -lcomdlg32 -lshell32 -limm32
../windows/libwidget_windows.a(nsDataObj.o):/mnt/dump/src/mozilla/mozilla/widget/src/windows/nsDataObj.cpp:411: undefined reference to `_IID_IAsyncOperation'
../windows/libwidget_windows.a(nsDragService.o):/mnt/dump/src/mozilla/mozilla/widget/src/windows/nsDragService.cpp:306: undefined reference to `_IID_IAsyncOperation'
collect2: ld returned 1 exit status

http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/lib/cguid-uuid.c?rev=1.2&content-type=text/x-cvsweb-markup&cvsroot=src indicates that extracting IIDs from the registry is okay; in that case, it's in mine as {3D8B0590-F691-11D2-8EA9-006097DF5BD4}

This would probably go into w32api / mingw upstream?

[Kai Tietz]

Logged In: YES
user_id=1598680
Originator: NO

Thank you very much for your try. This is really a very big help to stablize the compiler and add missing features to our crt.

The library libIDL we will build for 64-bit in next source release. We will add the feature.

About the missing library stubs libwinsock.a and libwsock32.a, we can add copies from the 64-bit supported libraries to support them. But the dll's winsock.dll and wsock32 are no longer supported AFAICS in 64-bit.

About the ICE appearing while compiling the nsCipherInfo.ii file, do you use the current linux cross-compiler from our site? Could you post the ICE position in gcc?

Thanks in advance,
Kai

[Mook]

Logged In: YES
user_id=2055712
Originator: YES

The ICE was the 20080404 i686->x86_64 snapshot from the downloads site, yes. The backtrace looks like:

(gdb) where
#0 internal_error (gmsgid=0x899e0ca "in %s, at %s:%d") at ../../gcc/gcc/diagnostic.c:598
#1 0x082bd2df in fancy_abort (file=0x89de4d4 "../../gcc/gcc/tree-ssa-address.c", line=603, function=0x89de5c8 "create_mem_ref")
at ../../gcc/gcc/diagnostic.c:654
#2 0x0856b25c in create_mem_ref (bsi=0xbfde871c, type=0xb6cfb3a8, addr=0xbfde8660) at ../../gcc/gcc/tree-ssa-address.c:603
#3 0x085c03c7 in rewrite_use_address (data=0xbfde891c, use=0x8c499c8, cand=0x8c2daa8) at ../../gcc/gcc/tree-ssa-loop-ivopts.c:5227
#4 0x085c3f4c in rewrite_uses (data=0xbfde891c) at ../../gcc/gcc/tree-ssa-loop-ivopts.c:5286
#5 0x085c8659 in tree_ssa_iv_optimize_loop (data=0xbfde891c, loop=<value optimized out>) at ../../gcc/gcc/tree-ssa-loop-ivopts.c:5485
#6 0x085c8c75 in tree_ssa_iv_optimize () at ../../gcc/gcc/tree-ssa-loop-ivopts.c:5518
#7 0x085d7295 in tree_ssa_loop_ivopts () at ../../gcc/gcc/tree-ssa-loop.c:580
#8 0x084276ef in execute_one_pass (pass=0x8ae7680) at ../../gcc/gcc/passes.c:1127
#9 0x084278f7 in execute_pass_list (pass=0x8ae7680) at ../../gcc/gcc/passes.c:1180
#10 0x0842790a in execute_pass_list (pass=0x8ae72c0) at ../../gcc/gcc/passes.c:1181
#11 0x0842790a in execute_pass_list (pass=0x8ae6b00) at ../../gcc/gcc/passes.c:1181
#12 0x08523dec in tree_rest_of_compilation (fndecl=0xb749e7e0) at ../../gcc/gcc/tree-optimize.c:420
#13 0x08715b98 in cgraph_expand_function (node=0xb6d17410) at ../../gcc/gcc/cgraphunit.c:1157
#14 0x0871817e in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1220
#15 0x0810c285 in cp_write_global_declarations () at ../../gcc/gcc/cp/decl2.c:3471
#16 0x084b192c in toplev_main (argc=13, argv=0xbfde8bf4) at ../../gcc/gcc/toplev.c:971
#17 0x08225792 in main (argc=1634296879, argv=0x736f6e67) at ../../gcc/gcc/main.c:35

[Mook]

Logged In: YES
user_id=2055712
Originator: YES

mingw-w64-headers/include/memory.h
line 24: _CONST_RETURN void *__cdecl memchr(void *_Buf ,int _Val,size_t _MaxCount);
The function is documented to take const void* as the first parameter. (string.h in the same directory has this too)

[Kai Tietz]

Logged In: YES
user_id=1598680
Originator: NO

Thank you for the hint for memchr declaration in memory.h. I corrected this already on our trunk (Rev. 318)

I was able to reproduce the ICE. It seems to be that for some reasons, the gimple makes out of a function a non r-value insn? This smell for a bug to be reported to gcc for ssa or gimple.

Kai

[Mook]

Logged In: YES
user_id=2055712
Originator: YES

Yay, something or other build (doesn't actually work, of course, since xptcinvoke and xptcstubs are both not implemented).

I'll file a mozilla bug for the symlinks for include:
Usp10.h -> usp10.h
WinCrypt.h -> wincrypt.h
Windows.h -> windows.h
WTypes.h -> wtypes.h

[Kai Tietz]

Logged In: YES
user_id=1598680
Originator: NO

If you need some assistance for the assembly port, feel free to e-mail me. In our Wiki you will find a description of the calling convention. This could be of some use for you.

[NightStrike]

Logged In: YES
user_id=1864092
Originator: NO

ICE's are fixed in GCC svn, and all toolchain builds after roughly April 10th.

[NightStrike]

Logged In: YES
user_id=1864092
Originator: NO

How is the build coming? What is your current roadblock?

[Kai Tietz]

Logged In: YES
user_id=1598680
Originator: NO

Hi,

I managed it to produce a more or less working gdb, which is capable to debug iceweasel without assert. There seems to be some problems in gcc with optimization -O2, which caused in cp_demangle.c of libiberty an exception. New gdb version is to be found in our download section as 'mingw-w64-gdb_20080417.tar.bz2'.

By the working gdb I found the reason for the iceweasel crash. The ctor section isn't aligned to a 8 byte boundary. I sent a patch to binutils for this.

Cheers,
Kai

[Mook]

Logged In: YES
user_id=2055712
Originator: YES

Jotting down some of the assertions I hit, now that it builds and gets further:

http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/caps/src/nsScriptSecurityManager.cpp&rev=1.361&mark=3270#3258 (wtf, Mozilla)
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/layout/build/nsLayoutModule.cpp&rev=1.185&mark=337#335 (I need to fix - http://mxr.mozilla.org/mozilla/search?string=PtrBits&find=\.h%24&findi=&filter=typedef.\*\bPtrBits&hitlimit=&tree=mozilla)
Followed by JS throwing in nsBrowserGlue.js (NS_ERROR_ILLEGAL_VALUE calling nsIPlacesImportExportService.importHTMLFromFile)
then a crash.

Going to try fixing the PtrBits stuff first, then play with GDB.

[NightStrike]

Logged In: YES
user_id=1864092
Originator: NO

As of gcc rev 134942, building anything with mmintrin.h should now be fixed. See this bug for reference:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36100

[NightStrike]

Logged In: YES
user_id=1864092
Originator: NO

new.h is fixed, and the build script now incorporates your changes

[NightStrike]

What is the current blocker for this?

[Nobody/Anonymous]

That I am a lazy bum who hasn't yet figured out the startup crash somewhere in the middle of calling CoCreateInstance near some drag-and-drop code. I think there might still be an instance of WinDbg sitting around somewhere with it open.

[NightStrike]

Lurker!! Get back into chat! :) :)

[Mook]

Ugh.

LCMS (the color correction library) depends on being able to do weird crap like:
typedef unsigned int DWORD;
typedef unsigned long DWORD;
/* that's just a warning, not a hard error, right? */

[Mook]

Ugh, nevermind that, it was funky #define rules.

Now hitting missing ITextStoreACP (http://msdn.microsoft.com/en-us/library/ms538384%28VS.85%29.aspx) and ITfContextOwnerCompositionSink (http://msdn.microsoft.com/en-us/library/ms538740%28VS.85%29.aspx) declarations...

[Mook]

Yay, have a working build. Still need to do:
1) #include <stddef.h> ends up including the gcc version, not the mingw version. This means no __int64 available... (Locally worked around by copying the mingw version over)
2) Need more MSCTF/textstor work. (I have a local patch for this, need to sort things out and make sure I didn't use any badly licensed code)
3) Needs more mozilla patches (my mq patch queue is http://bitbucket.org/mook/mozwin64/src/ at the moment)
4) More IIDs and CLSIDs. (I'm having trouble finding these with clearly acceptable licenses)

Surprisingly many of the Mozilla tests pass :D