During my work on migration from dmake to gnu make (gbuildification) of expat module i discovered some innocent looking lines in the old dmake based make file:
.IF "$(BUILD_X64)"!="" # ---------------- X64 stuff special --------------------- # use UNICODE only because shell/shlxthandler # doesn't link against ascii_expat_xmlparse #--------------------------------------------------------- SLOFILES_X64=$(SLO_X64)/xmlparse.obj \ $(SLO_X64)/xmlrole.obj \ $(SLO_X64)/xmltok.obj CDEFS_X64+=-DXML_UNICODE -DCOMPILED_FROM_DSP CFLAGS_X64+=-I.. LIB1TARGET_X64=$(SLB_X64)/$(TARGET)_xmlparse.lib LIB1OBJFILES_X64=$(SLO_X64)/xmlparse.obj LIB2TARGET_X64=$(SLB_X64)/$(TARGET)_xmltok.lib LIB2OBJFILES_X64=$(SLO_X64)/xmlrole.obj \ $(SLO_X64)/xmltok.obj .ENDIF # "$(BUILD_X64)"!=""
So what is BUILD_X64 here and when it is used? My understanding was, that LO isn’t shipping as 64 bit binary on Windows. Tor did some great work on it but it is still highly experimented. So what is all that stuff about? It turns out, that LO does shipp nativ 64 bit extension for 64 bit OS for shell integration and special version of expat (64 bit) must be created for that.
Not big deal, right? So what’s the problem with that? The problem was to test it. Gbuildification has already broken almoust everything, so before merging the gbuildified expat to master some real tests should be done, especially if some native bits are involved. Having only access to WinXP (32 bit) and VS 2008 Express was clearly not sufficient. So before installing a whole blown testbed with new VM, 2008 Server 64 bit, SDKs and 64 bit VS compiler i thought i would just ask the folks out there for help.
So i asked Norbert on LO congress to attach his 2008R2@16 tinderbox to my gerrit patch. He did (thank you Norbert!) and it failed. Unfortunatelly i din’t figure out how to access the error log for that. Well, i configured a new VM and installed Windows Server 2008, SDKs, VS 2008 Express compiler to test my patch. But the disappointment was really big: this configuration neither tested 64 bit shell extension nor did it test expat 64 bit code. As i understand now, VS express edition doesn’t ship 64 bit executables (or at least i didn’t figure out how to install that).
Having access to VS 2010 professional only, i found myself starting a new adventure: adjusting LO code to compile on that new compiler. Thank Peter’s work it almoust worked. I filed some changes in this gerrit patch link and updated the documentation correspondingly: here and here. One weird templating problem in writerfilter is still not solved, though: link. Any help here would be highly appreciated!
After all these tricky problems i could check my patch and found the problem. It was failing to link 64 bit native libs because of architecture mismatch: objects were (still) built with _X86_ but the lib was AMD64. The reason for that was: i forgot to extend the compilation to honour BUILD_X64 setting. So i introduced a new function and used it (in C++ case it was already there) and all was fine:
gb_StaticLibrary_add_x64_generated_cobjects
In the end i wanted to test the created msi file but was experiencing that weird msi installation problem: fdo#55290. It was clear that the problem was introduced with gbuildification of cli_ure module.
The comparison of verbose output of old dmake build and the new one reveals the different approaches in creating the native library. While in the old build system the library was created under the end name cli_cppuhelper.dll and signed afterwards, on the new gbuild system it was first created under the different name cli_cppuhelper_native.dll and then renamed during the signing step to the end name cli_cppuhelper.dll. This is due the fact, that in gbuild world we don’t want to mess with copying artifacts around: all libs are living under bin directory. That why that is natural on gbuild to prefer name differentiation over different directories.
But the problem is that the native library may not be renamed. If you look inside it (emacs) you can see that it “remembers” his name. Like always, the standard action sequence: “reproduce, isolate, find workaround, understand and fix” worked here.
After all, i am able to install a fresh built LibO-Dev_3.7.0.0.alpha0_Win_x86_install_en-US.msi, compiled with VS 2010 and contained gbuidified expat with 64 bit shell integration. But Michael Stahl merged my gerrit expat module already (thank you Michael!) and besides i have no idea how to test that LO shell integration? May be some one can point me to a RTFM or send me a screen shot: it would be nice to know why i was messing around with all that stuff. I wanted only gbuildify expat module … 😉
