<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_UNCONFIRMED " title="UNCONFIRMED - cli_cppuhelper policy installed in GAC for wrong architecture" href="https://bugs.documentfoundation.org/show_bug.cgi?id=144405#c8">Comment # 8</a> on <a class="bz_bug_link bz_status_UNCONFIRMED " title="UNCONFIRMED - cli_cppuhelper policy installed in GAC for wrong architecture" href="https://bugs.documentfoundation.org/show_bug.cgi?id=144405">bug 144405</a> from <a class="email" href="mailto:michael.stahl@allotropia.de" title="Michael Stahl (allotropia) <michael.stahl@allotropia.de>"> Michael Stahl (allotropia)</a> <pre>> 1. The policy.1.0.cli_cppuhelper.dll file has been built for x86; its CLR header has the 32BITREQUIRED flag, and evaluating 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... (... and java's model of putting .dll files into jars is so much easier to understand than this overengineered CLR nightmare of policy dlls, keyfiles, GAC, DLLs that may be native or may be portable, etc.) > the assembly is referenced by a Windows Installer package. I suspect this > mismatch originates from scp2/source/ooo/ure.scp, which unconditionally > specifies ProcessorArchitecture = "x86" for both > gid_File_Lib_Cli_Cppuhelper_Assembly and > gid_File_Lib_Policy_Cli_Cppuhelper_Assembly. sounds likely. (In reply to Kalle Niemitalo from <a href="show_bug.cgi?id=144405#c4">comment #4</a>) > The assembly version of cli_cppuhelper is defined in > cli_ure/version/version.txt. It was incremented to 1.0.23.0 for <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED FIXED - cli_ assemblies are not correctly versioned" href="show_bug.cgi?id=108709">bug #108709</a> > in August 2017, four years ago. That was then released in LibreOffice > 6.0.0.1, and now LibreOffice 7.2.0.4 and 7.2.1.2 are still using the same > assembly version. I think that means it is unlikely to be incremented again > any time soon. Therefore, an application that references cli_cppuhelper > version 1.0.23.0 will probably keep working even if this bug is not fixed > and LibreOffice is upgraded. well the idea was that release engineering would update the version numbers, but it looks like that didn't happen.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>