https://bugs.documentfoundation.org/show_bug.cgi?id=144405
--- Comment #13 from murphyde...@gmail.com ---
Upon further contemplation of the concept of dual-architecture operation, it is
evident that the cli_cppuhelper module employs a delay-loading mechanism for
the architecture-specific libraries
https://bugs.documentfoundation.org/show_bug.cgi?id=144405
Mike Kaganski changed:
What|Removed |Added
See Also||https://bugs.documentfounda
https://bugs.documentfoundation.org/show_bug.cgi?id=144405
Buovjaga changed:
What|Removed |Added
See Also||https://bugs.documentfounda
https://bugs.documentfoundation.org/show_bug.cgi?id=144405
--- Comment #12 from Kalle Niemitalo ---
(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://bugs.documentfoundation.org/show_bug.cgi?id=144405
--- Comment #11 from Julien Nabet ---
Kalle: reading your comments and seeing you've got some knowledge about Windows
internals, perhaps you may be interested in contributing?
If yes, here are 2 links:
1) general info about code contribu
https://bugs.documentfoundation.org/show_bug.cgi?id=144405
--- Comment #10 from Kalle Niemitalo ---
Thinking about dual-architecture operation some more -- cli_cppuhelper
delay-loads cppu3.dll and cppuhelper3MSC.dll, which are surely
architecture-specific. It wouldn't make sense to install an x8
https://bugs.documentfoundation.org/show_bug.cgi?id=144405
--- Comment #9 from Kalle Niemitalo ---
(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
https://bugs.documentfoundation.org/show_bug.cgi?id=144405
--- Comment #8 from Michael Stahl (allotropia) ---
> 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_plat
https://bugs.documentfoundation.org/show_bug.cgi?id=144405
--- Comment #7 from Stephan Bergmann ---
(In reply to Mike Kaganski from comment #6)
> @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
> fo
https://bugs.documentfoundation.org/show_bug.cgi?id=144405
Mike Kaganski changed:
What|Removed |Added
Keywords|difficultyMedium|
--- Comment #6 from Mike Kagans
https://bugs.documentfoundation.org/show_bug.cgi?id=144405
Roman Kuznetsov <79045_79...@mail.ru> changed:
What|Removed |Added
Blocks||113117
https://bugs.documentfoundation.org/show_bug.cgi?id=144405
Julien Nabet changed:
What|Removed |Added
CC||michael.st...@allotropia.de
https://bugs.documentfoundation.org/show_bug.cgi?id=144405
--- Comment #4 from Kalle Niemitalo ---
The assembly version of cli_cppuhelper is defined in
cli_ure/version/version.txt. It was incremented to 1.0.23.0 for bug #108709 in
August 2017, four years ago. That was then released in LibreOffice
https://bugs.documentfoundation.org/show_bug.cgi?id=144405
kalle.niemit...@procomp.fi changed:
What|Removed |Added
Keywords||difficultyMedium
---
https://bugs.documentfoundation.org/show_bug.cgi?id=144405
--- Comment #2 from kalle.niemit...@procomp.fi ---
According to Bug #94265 comment #22, nightly builds do not register their files
the same way as releases, unless given a specific parameter. I don't know
whether that is still true. Anyway
https://bugs.documentfoundation.org/show_bug.cgi?id=144405
--- Comment #1 from kalle.niemit...@procomp.fi ---
This bug might not affect applications running on .NET Core or .NET 5 or 6,
because assembly resolution is so different there. But I don't know whether the
CLI Language Binding assemblies
16 matches
Mail list logo
