[Libreoffice-bugs] [Bug 144405] cli_cppuhelper policy installed in GAC for wrong architecture

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=144405

--- Comment #12 from Kalle Niemitalo <Kalle.Niemitalo at procomp.fi> ---
(In reply to Kalle Niemitalo from comment #0)

> 1. The policy.1.0.cli_cppuhelper.dll file has been built for x86

I think this can be fixed by changing gb_CliNativeLibrary_PLATFORM_DEFAULT
here:

https://opengrok.libreoffice.org/xref/core/solenv/gbuild/CliNativeLibrary.mk?r=0adc9b61#12

The value is currently always x86.  If the amd64 build of LibreOffice instead
used amd64 here too, I think this setting would get passed to the "al" command
and policy.1.0.cli_cppuhelper.dll would get the correct architecture in its
headers, causing Fusion to install it to GAC_64 rather than GAC_32.  It would
still be possible to override this default by calling
gb_CliNativeLibrary_set_platform for individual libraries, should that ever
become necessary.


> 2. ORCA shows that the MsiAssemblyName table of the MSI package has
> processorArchitecture=x86 for both cli_cppuhelper and
> policy.1.0.cli_cppuhelper.

processorArchitecture of policy.1.0.cli_cppuhelper is defined for the
MsiAssemblyName table here:

https://opengrok.libreoffice.org/xref/core/scp2/source/ooo/ure.scp?r=0adc9b61#210

If gb_CliNativeLibrary_PLATFORM_DEFAULT is conditionally changed to "amd64",
then the same change should be made here as well.


processorArchitecture of cli_cppuhelper is defined for the MsiAssemblyName
table here:

https://opengrok.libreoffice.org/xref/core/scp2/source/ooo/ure.scp?r=0adc9b61#197

Correcting that might have no effect on cli_cppuhelper assembly loading, but it
could instead fix Bug#101200 (cli_cppuhelper not uninstalled from GAC).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20210918/aa0baef2/attachment.htm>