#1 Building Firefox with 64-bit MinGW

open
nobody
5
2008-04-07
2008-04-06
Mook
No

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

Discussion

  • Mook
    Mook
    2008-04-06

    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
    Mook
    2008-04-06

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

     
    Attachments
  • Mook
    Mook
    2008-04-06

    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
    Mook
    2008-04-06

    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
    Kai Tietz
    2008-04-06

    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
    Mook
    2008-04-06

    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
    Mook
    2008-04-06

    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
    Kai Tietz
    2008-04-06

    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
    Mook
    2008-04-07

    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
    Kai Tietz
    2008-04-07

    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.

     
  • Kai Tietz
    Kai Tietz
    2008-04-07

    • labels: --> Build 3rd party app
    • status: open --> pending
     
  • NightStrike
    NightStrike
    2008-04-07

    • status: pending --> open
     
  • NightStrike
    NightStrike
    2008-04-14

    Logged In: YES
    user_id=1864092
    Originator: NO

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

     
  • NightStrike
    NightStrike
    2008-04-16

    Logged In: YES
    user_id=1864092
    Originator: NO

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

     
  • Kai Tietz
    Kai Tietz
    2008-04-17

    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

     
  • NightStrike
    NightStrike
    2008-05-05

    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
    NightStrike
    2008-05-07

    Logged In: YES
    user_id=1864092
    Originator: NO

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

     
  • NightStrike
    NightStrike
    2008-12-27

    What is the current blocker for this?

     
  • 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
    NightStrike
    2008-12-27

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

     
  • Mook
    Mook
    2009-02-22

    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
    Mook
    2009-02-22

    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
    Mook
    2009-08-30

    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