Steps to reproduce: 1. Open Writer 2. File - Wizards - Document Converter -> BASIC runtime error Reproduced in Version: 25.8.0.0.beta1+ (X86_64) / LibreOffice Community Build ID: 211c193b1c7391b4f1c1172214a90899de19b06a CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: es-ES (es_ES.UTF-8); UI: en-US Calc: threaded
Regression introduced by: commit ea2a97438643a440e192dbe30d03988da65c6b18 [log] author Mike Kaganski <mike.kaganski@collabora.com> Sun Dec 01 14:25:12 2024 +0500 committer Mike Kaganski <mike.kaganski@collabora.com> Sun Dec 01 12:27:02 2024 +0100 tree ca8bb550c9c5c515ef0366b6c17f027fc5ca0511 parent e413d962ac6f4cc6c32bd153a030a57a57d66676 [diff] Simplify NameContainer
Just uncovered a pre-existing issue, hidden by accident by the previous name order of modules. Consider this: LibraryX ModuleA Public Const MAXLEN = 10 ModuleB Public X(MAXLEN) As String In this case, the author expects that the constant MAXLEN defined in ModuleA is available in ModuleB; but it depends on the order in which the modules are loaded. And previously, the order was lexicographical (but not because it was a specification, or explicitly made so in implementation - just because that was the order in which the module names happened to be added in this specific Basic source XML); but now NameContainer::getElementNames was reimplemented to return the order that unordered_map produces (which is implementation-defined), and on Linux, it returns "Language" before "DialogModul" -> the constants in the latter are unavailable in the former. On Windows (i.e., with the current implementation of unordered_map in MS STL), it happens to work. As a workaround, I will sort the modules in library load procedure; but this is a general bug.
https://gerrit.libreoffice.org/c/core/+/187081
Removing regression keyword based on comment 1. Thanks for the explanation Mike
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e21c27ae301dc1a3d55563e0b7428adc189804bc tdf#167255: workaround undefined order of module load It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/9522aeae871b6ca71c664fba7c7b8677ff4b2b69 tdf#167255: workaround undefined order of module load It will be available in 25.2.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-25-8": https://git.libreoffice.org/core/commit/36836b5466243c803e0011473bc1f5c2a81f55db tdf#167255: workaround undefined order of module load It will be available in 25.8.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.