<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#c7">Comment # 7</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:sbergman@redhat.com" title="Stephan Bergmann <sbergman@redhat.com>"> Stephan Bergmann</a> <pre>(In reply to Mike Kaganski from <a href="show_bug.cgi?id=144405#c6">comment #6</a>) > @Stephan: I suppose that cli_cppuhelper can't be "cpu-neutral"; if so, > should we bundle two versions of cli_cppuhelper (and related policy), one > for 32-bit processes, and one for 64-bit, each in respective GAC? Or does > CLI allow to have only one such library, and use it in all processes > (32/64/neutral)? I know very little about CLI, the CLI UNO bridge, GAC, etc. That said, the 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. 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. 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>