[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 #9 from Kalle Niemitalo <Kalle.Niemitalo at procomp.fi> ---
(In reply to Stephan Bergmann from comment #7)

> cli_cppuhelper.dll is built by cli_ure/CliNativeLibrary_cli_cppuhelper.mk,
> so I would naively assume that it contains native (x86 vs. x86-64) code.

It contains both native code and managed code, and the C++/CLI compiler may
have hardcoded values that depend on sizeof(void*) in each.

> My guess is that places that indicate 32-bit x86 rather than 64-bit
> x86-64/amd64 even for a 64-bit LO build on Windows are accidental leftovers
> that were not properly adapted when that 64-bit configuration was added back
> in the day.

That is my guess as well.

> I don't see a reason to bundle two versions of cli_cppuhelper.  I would
> assume that users who want to interact with LO from a 32-bit CLI environment
> install the 32-bit LO version, and users who want to interact from a 64-bit
> CLI environment install the 64-bit version.

If a user needs to access LibreOffice from both x86 and amd64 CLI processes,
then that is currently cumbersome, because the x86 and amd64 builds of
LibreOffice apparently cannot be installed side by side.  It could thus be
useful to have both x86 and amd64 binaries of cli_cppuhelper and
policy.1.0.cli_cppuhelper in the amd64 LibreOffice package.  I think that can
be handled as a separate feature request, though.

(Installing the 7.2.0.4 x86 build uninstalled the amd64 build, but the
uninstallation left the amd64 binary of cli_cppuhelper in the GAC.  I don't yet
know whether it will be removed after the next reboot or whether it was
permanently leaked because of the incorrect data in the MsiAssemblyName table.)

(In reply to Michael Stahl (allotropia) from comment #8)

> hmm... there is a function gb_CliAssemblyTarget_set_platform that would
> cause a "-platform" argument to be passed but it has never been used in the
> build system.
> 
> probably only the native code library would require it? guess it should be
> set from the constructor gb_CliNativeLibrary_CliNativeLibrary then...

As of libreoffice-7.2.0.4, gb_CliNativeLibrary_CliNativeLibrary calls $(call
gb_CliAssembly_set_platform,$(1),$(gb_CliNativeLibrary_PLATFORM_DEFAULT)), and
gb_CliAssembly_set_platform then forwards to gb_CliAssemblyTarget_set_platform.
 gb_CliNativeLibrary_PLATFORM_DEFAULT however is defined as x86 and I haven't
found anything that would change it.  Is that what assigns the incorrect
platform to the policy assembly?

The Jenkins log
https://ci.libreoffice.org/job/lo_daily_tb_win_7-2/80/consoleText unfortunately
does not show the commands with which policy.1.0.cli_cppuhelper was built.

-- 
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/20210917/ba818009/attachment.htm>