Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index

Re: [tdf-discuss] Re: Will win64 native build exist on 3.5.0 or at least 3.5.x releases?

Il 02/11/2011 13:39, Tor Lillqvist ha scritto:
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.

Hi Tor,

first of all and in front of this 360 degrees answer, I must and I want to thank you a lot! :-)

I reach the end without any other doubt or question. I agree with you at all.

I use a 64 bit Linux Libò from start (now vanilla only) and before Go-OO from OpenSuSE Build Service. I think we have some time in front of us so we could start complete your excellent work within some steps, projects, University and PhD Thesis, Sponsorship and so on...

Why? Because only when will get Mars we are able to understand what exactly could we do there!!! ;-) ;-) ;-) (Take a look to what Internet is today, to what Facebook and Social Networks have driven Nord African and Middle Est People, ...: have you told this at Internet start?).

Have a nice day/evening,


Unsubscribe instructions: E-mail to
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.