basic/source/uno/namecont.cxx | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
New commits:
commit e21c27ae301dc1a3d55563e0b7428adc189804bc
Author: Mike Kaganski <mike.kagan...@collabora.com>
AuthorDate: Fri Jun 27 09:56:15 2025 +0200
Commit: Mike Kaganski <mike.kagan...@collabora.com>
CommitDate: Fri Jun 27 11:43:55 2025 +0200
tdf#167255: workaround undefined order of module load
The problem is, that there is no definition of resolution of name
visibility, when names are defined in different modules. Before
commit ea2a97438643a440e192dbe30d03988da65c6b18 (Simplify
NameContainer, 2024-12-01), it happened to be the order in which
modules were found in SfxLibraryContainer::init_Impl (it could be
arbitrary in principle).
The said commit changed NameContainer::getElementNames to return
the names in ~arbitrary order (defined by specific unordered_map
implementation).
To workaround the current problem (when 'SBMAXAPPLCOUNT' defined
in 'DialogModul' of 'ImportWizard' library is not visible in its
'Language' module at library load time, specifically on Linux),
just sort the library element names at its loading time. It will
not create performance problem (it is a one-time sort over a small number
of elements; having millions of modules in a single library
is not realistic, and would create bigger problems elsewhere).
Change-Id: I93e91ae5f4be12a1bf641fe2d29e0a161589b8af
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187081
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kagan...@collabora.com>
diff --git a/basic/source/uno/namecont.cxx b/basic/source/uno/namecont.cxx
index 5436b3c6c380..db97fe8794b3 100644
--- a/basic/source/uno/namecont.cxx
+++ b/basic/source/uno/namecont.cxx
@@ -2304,7 +2304,17 @@ void SfxLibraryContainer::loadLibrary_Impl(const
OUString& Name,
#endif
}
- for (auto& aElementName : pImplLib->getElementNames())
+ // tdf#167255 workaround: sort library elements to establish at least some
predictable order.
+ // FIXME: the order of modules must not affect their inner names
visibility. Modules must load
+ // their content first (and so the names of e.g. global constants /
variables must be known),
+ // and only then their elements' values must be resolved.
+ auto elements = pImplLib->getElementNames();
+ {
+ auto range = asNonConstRange(elements);
+ std::sort(range.begin(), range.end());
+ }
+
+ for (auto& aElementName : elements)
{
OUString aFile;
uno::Reference< io::XInputStream > xInStream;
