Windows 64bit release - Githubissues

anaisbetts commented 9 years ago

I would be into this

zcbenz commented 9 years ago

We need to add 64bit build in libchromiumcontent first, I had tried in the cross-build branch a few months ago but got stuck by some WebKit building errors. After many Chrome releases I guess things should be better now.

50Wliu commented 9 years ago

I would love to see this :).

JeffreyHyer commented 9 years ago

:+1:

frankhale commented 9 years ago

FWIW, Node-Webkit is shipping 64bit binaries for Windows now. Hopefully it won't be a whole lot of trouble.

carstenhag commented 9 years ago

:+1:

jeremysmartt commented 9 years ago

Would love to use this on a project but 64bit Windows is a must. Noticed that Node-Webkit has 64bit, would rather use atom-shell but might be forced to use Node-Webkit if 64bit atom-shell won't be completed soon. Any idea of the timeline on this? Thanks and atom-shell is a very cool!

bwin commented 9 years ago

@mrjayhawk why does it have to be 64bit?

carstenhag commented 9 years ago

^ @mrjayhawk 64bit is nice and all but I don't see why it is mission critical.

jeremysmartt commented 9 years ago

@Moter8 @bwin if you are using native modules that need to link with other 64 bit native code I am pretty sure we need it to be 64 bit also?

fnkr commented 9 years ago

+1

ghost commented 9 years ago

Is there any estimate of when it will be possible to build 64-bit desktop applications using atom-shell? We have a millions of lines existing C++ code of our own, plus 3rd party, that we only build in 64-bit mode. We would rather use atom-shell than node-webkit, but the lack of support for 64-bit by atom-shell is a show stopper. We might try to build it ourselves but do not want to spend time on it if this is something that is already planned to be worked on soon.

anaisbetts commented 9 years ago

We might need this sooner rather than later - @zcbenz, is there a good place I could start hacking on this? I assume brightray/libchromiumcontent is a good place to start

zcbenz commented 9 years ago

@paulcbetts Yeah once we had the 64bit build of libchromiumcontent things will be straight to go. Last time when I tried it I encountered a weird building problem from WebKit, you can have a try in cross-build branch, I have rebased it on master but not tested it.

anaisbetts commented 9 years ago

@zcbenz I'm poking at it now, getting tripped up on some stupid stuff though (can't find the Windows SDK). Will report back if I can get around it

anaisbetts commented 9 years ago

Looks like we're running up against size limits again (/cc @aroben who I believe hacked on this the first time):

C:\Users\Paul\code\brightray\libchromiumcontent> python script\build
ninja: Entering directory `vendor\chromium\src\out\Debug_x64'
[7493/11376] LIB obj\third_party\WebKit\Source\core\webcore_remaining.lib
FAILED: C:\Python27\python.exe gyp-win-tool link-wrapper environment.x64 False lib.exe /nologo /ignore:4221 /OUT:obj\third_party\WebKit\Source\core\webcore_remaining.lib@obj\third_party\WebKit\Source\core\webcore_remaining.lib.rsp
LINK : fatal error LNK1248: image size (802BECBB) exceeds maximum allowable size (80000000)
[7493/11376] CXX obj\third_party\WebKit\Source\core\rendering\webcore_rendering.RenderButton.obj
ninja: build stopped: subcommand failed.
Traceback (most recent call last):
  File "script\build", line 43, in <module>
    sys.exit(main())
  File "script\build", line 33, in main
    subprocess.check_call([NINJA, '-C', config_dir] + TARGETS)
  File "C:\Python27\lib\subprocess.py", line 540, in check_call
    raise CalledProcessError(retcode, cmd)

MetaMemoryT commented 9 years ago

What do you think is contributing most to the size, inline functions?

anaisbetts commented 9 years ago

@MetaMemoryT lol, I think the millions of lines of C++ code are contributing to the size

jeremysmartt commented 9 years ago

@paulcbetts Were you able to make any progress on the "exceeds maximum allowable size" error?

anaisbetts commented 9 years ago

@mrjayhawk No, I have no idea how to fix this :(

ghost commented 9 years ago

I will start looking into this today and continue looking into it as time allows. currently building 32-bit debug of brightray/libchromiumcontent (cross-build) as a confidence factor, just to make sure i can build what is supposed to build before looking into what does not build. i will keep everyone posted.

ghost commented 9 years ago

This probably is not telling you guys any more than you already know:

From https://msdn.microsoft.com/en-us/library/1cbeb9f0.aspx

image size ('size') exceeds maximum allowable size (80000000)

The linker determined that the size of the output file will exceed the largest possible size for a program image. You may want to make your program into multiple DLLs. For more information on the program executable (PE), see the article "Peering Inside the PE: A Tour of the Win32 Portable Executable File Format" in the MSDN Library.

"Steve Lionel (Intel) Wed, 01/25/2012 - 08:03 It is a problem. Windows limits static code and data to 2GB, and you have exceeded this. Even on 64-bit Windows, no matter how much memory you have, the 2GB limit for static (non-allocatable) data remains.

The solution is to change the arrays from being declared with fixed bounds to being allocatable, and then using ALLOCATE to make them the desired size. If you are on a 64-bit system, this will allow you to have larger arrays. But if you are on a 32-bit system, you cannot go larger than 2GB."

From https://groups.google.com/a/chromium.org/forum/#!topic/chromium-reviews/ve7E2MbE9TY:

win: use /maxilksize on link to avoid LNK1248 'exceeds maximum allowable size (80000000)'

Not sure if any of this information helps. So far, I have not been able to get far enough into the build to get the error. On my machine, the 64-bit builds error out almost immediately for other reasons.

frankhale commented 9 years ago

Note, this is a naive response on my part. Node-Webkit has a different build process but they are able to accomplish a 64 bit build on Windows, granted it looks like the Chromium content layer is statically linked in the NW.exe. The size of the resulting exe is almost identical to the size of the chromium content DLL. Has anyone studied their build process to determine how they do it? Is this max size issue a DLL issue? Would Atom-Shell staff be willing to entertain a discussion of statically linking the Chromium content layer (brightray / libchromiumcontent) in Atom-Shell to achieve this? Perhaps that approach just on Windows for people who want a 64 bit build. Of course I'm over simplifying this, I have no idea what real hard work would need to take place to make this work. I'm just trying to lubricate the gears of thoughts and ideas and see if we can move this along.

aroben commented 9 years ago

Chromium has two different ways of building:

Chromium's release builds build a bunch of static libraries, then link them into the final Chrome DLLs. By linking everything into a single DLL that only exports the few functions that are needed by chrome.exe, the compiler/linker can eliminate dead code and perform whole-module optimizations. So this results in the smallest and fastest code.
A "component build" builds many smallish DLLs. This is used by Chromium developers as it speeds up incremental builds significantly (because in many cases you can get away with just recompiling the small DLL for the module you're working on). The DLLs end up being bigger in aggregate than the release build, and they aren't as fast due to all the cross-module calls that have to take place. This also requires each component to declare what symbols it needs to export so that other components higher up the dependency chain can call into them.

libchromiumcontent, which is used by atom-shell, builds yet another way: we compile all of Chromium into a single DLL, and reexport all the public symbols of all the component DLLs. This has the benefit of being simple for building against (just link against this one DLL and you're done) but results in a very large DLL (due to all the exported symbols) and probably isn't as fast as Chromium's release builds. It's also a bit of a pain to maintain this custom build process.

I've talked with @zcbenz in the past about switching to using Chromium's two standard build styles. Basically we'd generate two versions of libchromiumcontent: a component build that can be used during development, and a release build that can be used for releases. It will be a little more work to set up atom-shell's build system to link in these two cases, but I believe will result in a smaller atom-shell package and hopefully faster code. And it should be able to link on Windows.

jeremysmartt commented 9 years ago

@zcbenz Is breaking up the builds to allow for 64bit Windows something you see could be accomplished relatively easily?

ghost commented 9 years ago

I was not able to fix this. I will continue to use node-webkit for developing against our 64-bit only libraries and switch to atom-shell if this gets resolved at some point in the future.

zcbenz commented 9 years ago

Initial work has started at https://github.com/atom/libchromiumcontent/pull/98.

jeremysmartt commented 9 years ago

@zcbenz