Here is a report I wrote after working on x64 Windows LO compilation during Novell Hack Week back in February. No further work has been done. Everything done is in git.
I worked on making LibreOffice build as x64 (AMD64) code on Windows. I used the same compiler suite as normally when building current LibreOffice, i.e. Microsoft's Visual C++ 2008, just the x64 toolchain instead of the x86 one. My goal was not to produce a complete installable build just in one week, but to show that it can be done and get so far that at least some tests run successfully, and there I succeeded. Porting LibreOffice to a new platform consists of some trivial tasks like defining new LibreOffice internal codenames and whatnot for the platform, one hard bit: Porting the so-called C++-UNO bridge to the platform, and then a bunch of unexpected less hard stuff. Porting the C++-UNO bridge requires knowing the platform calling convention and exception handling in minute details. Dynamic generation of code for short "trampolines" is involved, so some assembly knowledge is required. Also a small amount of "normal" (non-dynamically-generated) assembly code. The x64 Windows calling convention is luckily quite clean, simple and thus IMHO elegant. Dare I say that it is more elegant than the AMD64 System V ABI used on Linux, with its complex rules on how to allocate registers for parameters. Sure, thanks to the simplicity, it uses much fewer registers for parameter passing than the Linux one. There are always a maximum of four parameters passed in registers, either integer or floating point ones. One parameter always takes one register, parameters larger than 64 bits are always passed through pointers. The exception handling mechanism used by MSVC on x64 is complex, but luckily it is roughly similar to that on x86 Windows. In addition to the trivial tasks and the C++-UNO bridge, there were of course a bunch of minor changes needed here and there to get the code to compile. After all, x64 Windows is different from all (?) other 64-bit platforms in that the long type is 32 bits. The LibreOffice codebase is famous for its age and messiness, and consistent use of sane integral types is not one of its strong points. For instance, there is an infamous legacy type in LibreOffice's "solar" layer called ULONG which surprisingly isn't typedeffed as (effectively) unsigned long, as one might suspect from its name, but as uintptr_t. That type is then mostly used as if it was unsigned long anyway, for instance there were a few assumptions that unsigned long literals like 42UL are of ULONG type. Of course, on other 64-bit platforms it doesn't matter, as both unsigned long and uintptr_t are 64 bits anyway, but this broke the compilation in a couple of places. There were a mass of warnings, obviously, as the code converts liberally back and forth between integral types . It remains to be seen then once the actual LibreOffice application is running on x64 Windows how many of those warnings actually cause run-time issues. So what did I then achieve, concretely? 1) most (maybe all even, I haven't verified exactly) of LibreOffice compiles as x64 Windows code. 2) The extensive C++-UNO bridge test in "testtools" runs fine as long as one comments out the exception handling testing. What remains to be done? 1) The exception handling part of the C++-UNO bridge. I worked on this last night and think it should be achievable. I have found good 3rd-party documentation on how it works, open source code even, and understand basically what the existing code for 32-bit Windows is doing, and what the x64 one should do. 2) Enabling also Java and the Mozilla bits in the build. I disabled them for now when building, didn't want to get stuck on those parts. 3) Verifying that the whole monster then actually runs. 4) Building an actual installer for it. Hopefully the installer-building mechanism doesn't even need to be aware that it is building an installer for 64-bit code. How useful is this work? That is a hard question. As such, running LibreOffice as a 32-bit process "should be enough for everybody". It's hard to imagine a situation where one would need to manipulate gigabyte-sized documents in LibreOffice. On Windows there isn't the same concern as on Linux where one wants to avoid needing to have both 32- and 64-bit libraries installed; at least so far all 64-bit Windows editions provide the full set of system libraries as both 64- and 32-bit. But it was a *very* interesting thing to hack on. And it might eventually be a nice feature for LibreOffice, at least among the slightly clueless who think 64-bit code is inherently better than 32-bit code on a 64-bit OS. And who knows, maybe some day Intel or AMD produce x64 CPUs that don't have 32-bit mode any more, and there are corresponding Windows editions that are 64-bit only. -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted