[tdf-discuss] Re: Will win64 native build exist on 3.5.0 or at least 3.5.x releases?
In my opinion TDF and LibreOffice should abandon the MS compiler and support the switch to MinGW which has already been started by Jan Holesovsky (aka Kendy) This would also open the path to using MinGW64 and therefore the creation of a native 64bit version of LO... The fact that it is a requirement to use a specific proprietary compiler to compile a FLOSS program makes the same sense as offering a free complete car (wheels, tires, etc) but to assemble it you would need to buy a wrench which is sold by a single company... Just my 2 cents. -- View this message in context: http://nabble.documentfoundation.org/Will-win64-native-build-exist-on-3-5-0-or-at-least-3-5-x-releases-tp3473463p3473622.html Sent from the Discuss mailing list archive at Nabble.com. -- 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
[tdf-discuss] Re: Will win64 native build exist on 3.5.0 or at least 3.5.x releases?
Pedro gmail.com> writes: > In my opinion TDF and LibreOffice should abandon the MS compiler and support > the switch to MinGW which has already been started by Jan Holesovsky (aka > Kendy) Actually the work to support MinGW was started already back in Sun/Oracle OOo times, and then continued for LO especially (and only) in the form of support for MinGW cross-compilation, by me and Kendy. > This would also open the path to using MinGW64 and therefore the creation of > a native 64bit version of LO... Well, glueing wings onto cows doesn't make them fly; there is also C++/UNO bridge code to write for this particular copiler/platform combination, and an unknown amount of other details here and there. Presumably it shouldn't be that different from the 64-bit MSVC work (modulo assembler syntax and whatnot), but that is not complete either. > The fact that it is a requirement to use a specific proprietary compiler to > compile a FLOSS program makes the same sense as offering a free complete car > (wheels, tires, etc) but to assemble it you would need to buy a wrench which > is sold by a single company... Car analogies are stupid. --tml -- 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
[tdf-discuss] Re: Will win64 native build exist on 3.5.0 or at least 3.5.x releases?
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/mai
[tdf-discuss] Re: Will win64 native build exist on 3.5.0 or at least 3.5.x releases?
carlo.strata wrote: > > Hi Pedro and Tor, > > What do you think about that? > I think that LibreOffice should use an Open Source compiler. I also think that most of the LibreOffice Devs don't use the Office programs they are developing on a daily basis as a production tool. If they did, it would be obvious to them that an x64 build is needed to work on heavy documents. In any case this is just my personal opinion. -- View this message in context: http://nabble.documentfoundation.org/Will-win64-native-build-exist-on-3-5-0-or-at-least-3-5-x-releases-tp3473463p3478780.html Sent from the Discuss mailing list archive at Nabble.com. -- 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
[tdf-discuss] Re: Will win64 native build exist on 3.5.0 or at least 3.5.x releases?
Jesús Corrius-2 wrote: > > If a heavy document doesn't work with the current x86 builds, please > open a bug report and attach the document to it. The more of them we > collect, the more obvious would be that we have to migrate. > I must admit I considered the option of answering you in catalá slang. It is a shame that this is the answer from a Deputy of the Board of Directors... BTW I didn't mention the word migrate. -- View this message in context: http://nabble.documentfoundation.org/Will-win64-native-build-exist-on-3-5-0-or-at-least-3-5-x-releases-tp3473463p3481470.html Sent from the Discuss mailing list archive at Nabble.com. -- 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
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
Re: [tdf-discuss] Re: Will win64 native build exist on 3.5.0 or at least 3.5.x releases?
Hi Pedro, Il 02/11/2011 13:19, Pedro ha scritto: In my opinion TDF and LibreOffice should abandon the MS compiler and support the switch to MinGW which has already been started by Jan Holesovsky (aka Kendy) I think we could put here, at least, the links: http://en.wikipedia.org/wiki/MinGW http://www.mingw.org/ http://mingw-w64.sourceforge.net/ for interested people... This would also open the path to using MinGW64 and therefore the creation of a native 64bit version of LO... I follow some and various FLOSS projects that are both and natively win32/win64 like these: http://7-zip.org/ http://infrarecorder.org/ (If I don't remember wrong, it use MinGW.) http://www.virtualdub.org/ http://sourceforge.net/projects/free-cad/ and http://free-cad.sourceforge.net/ ... and some that try to go win64 too, but without official courage, bravery, fearlessness http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/ ... and some that are not trying at all http://filezilla-project.org http://notepad-plus-plus.org/ ... Could we understand and learn somethings from above projects' choices and code? The fact that it is a requirement to use a specific proprietary compiler to compile a FLOSS program makes the same sense as offering a free complete car (wheels, tires, etc) but to assemble it you would need to buy a wrench which is sold by a single company... There are pros and cons to use Microsoft native and MinGW/GW64 compilers and libs, I suppose. Just my 2 cents. Have a nice evening, Carlo -- 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
Re: [tdf-discuss] Re: Will win64 native build exist on 3.5.0 or at least 3.5.x releases?
Hi Pedro and Tor, I forgot to mention another two win32/win64 big and famous open source appliances: - MySql (!) http://www.mysql.com/downloads/mysql/#downloads - PostgreSql (!) http://www.postgresql.org/download/windows About PostgreSql (that I installed, I used, I designed, I used to develop appliances (SQL, Pg-Pl/Sql) in the past) there is a very interesting page that could also help us http://wiki.postgresql.org/wiki/64bit_Windows_port that was about the win32 -> win64 port. Since version 9.0, EnterpriseDB deploy and make it available both windows installers and builds (win32 and win64). What do yuo think about that? Have a nice evening, Carlo Il 02/11/2011 20:22, Carlo Strata ha scritto: Hi Pedro, Il 02/11/2011 13:19, Pedro ha scritto: In my opinion TDF and LibreOffice should abandon the MS compiler and support the switch to MinGW which has already been started by Jan Holesovsky (aka Kendy) I think we could put here, at least, the links: http://en.wikipedia.org/wiki/MinGW http://www.mingw.org/ http://mingw-w64.sourceforge.net/ for interested people... This would also open the path to using MinGW64 and therefore the creation of a native 64bit version of LO... I follow some and various FLOSS projects that are both and natively win32/win64 like these: http://7-zip.org/ http://infrarecorder.org/ (If I don't remember wrong, it use MinGW.) http://www.virtualdub.org/ http://sourceforge.net/projects/free-cad/ and http://free-cad.sourceforge.net/ ... and some that try to go win64 too, but without official courage, bravery, fearlessness http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/ ... and some that are not trying at all http://filezilla-project.org http://notepad-plus-plus.org/ ... Could we understand and learn somethings from above projects' choices and code? The fact that it is a requirement to use a specific proprietary compiler to compile a FLOSS program makes the same sense as offering a free complete car (wheels, tires, etc) but to assemble it you would need to buy a wrench which is sold by a single company... There are pros and cons to use Microsoft native and MinGW/GW64 compilers and libs, I suppose. Just my 2 cents. Have a nice evening, Carlo -- 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
Re: [tdf-discuss] Re: Will win64 native build exist on 3.5.0 or at least 3.5.x releases?
> I also think that most of the LibreOffice Devs don't use the Office programs > they are developing on a daily basis as a production tool. If they did, it > would be obvious to them that an x64 build is needed to work on heavy > documents. If a heavy document doesn't work with the current x86 builds, please open a bug report and attach the document to it. The more of them we collect, the more obvious would be that we have to migrate. -- Jesús Corrius Deputy of the Board of Directors The Document Foundation Mobile: +34 661 11 38 26 Skype: jcorrius | Twitter: @jcorrius -- 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
Re: [tdf-discuss] Re: Will win64 native build exist on 3.5.0 or at least 3.5.x releases?
> I must admit I considered the option of answering you in catalá slang. > > It is a shame that this is the answer from a Deputy of the Board of > Directors... Sorry for my last message. It wasn't my intention to be offensive. -- Jesús Corrius Deputy of the Board of Directors of the Document Foundation Mobile: +34 661 11 38 26 Skype: jcorrius | Twitter: @jcorrius -- 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
