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.
Created attachment 204419 [details] .
Created attachment 204420 [details] Mac details
Use wizard to create table not working. "LibreOffice requires Oracle's Java Development Kit (JDK) on macOS 10.10 or greater to perform this task. Please install them and restart LibreOffice. https://hub.libreoffice.org/InstallJava/?LOlocale=en-US". Java is up to date on the computer, and still not working