...as emsdk 5.0.3 deprecated the predefined EMSCRIPTEN macro (see
<https://github.com/emscripten-core/emscripten/commit/506052bd8b4e23ded7f2351c62ca3b24d40c8cf3>
"Warn about usage of deprecated EMSCRIPTEN macro. NFC (#26381)"), causing
failures like
> In file included from static/source/unoembindhelpers/PrimaryBindings.cxx:29:
> In file included from include/sfx2/viewsh.hxx:35:
> In file included from include/editeng/outliner.hxx:32:
> In file included from include/tools/color.hxx:26:
> include/osl/endian.h:66:15: error: macro 'EMSCRIPTEN' has been marked as deprecated: use __EMSCRIPTEN__ instead [-Werror,-Wdeprecated-pragma]
> 66 | #elif defined EMSCRIPTEN
> | ^
> /home/sberg/emsdk/5.0.4/emsdk/emscripten/main/cache/sysroot/include/emscripten/emscripten.h:35:66: note: macro marked 'deprecated' here
> 35 | #pragma clang deprecated(EMSCRIPTEN, "use __EMSCRIPTEN__ instead")
> | ^
To avoid confusion, also suppress the -D$(OS) in
solenv/gbuild/platform/unxgcc.mk that would unnecessarily keep defining
EMSCRIPTEN.
Change-Id: Ic1f187cf1c6417cd95d4092e9cea01a665bd1b2f
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/34
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 50291c2ed83bdb49bb827a4a12905d94b8c42035)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205167
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
So far, Application::GetDesktopEnvironment was returning
a string to identify the desktop environment
(or OS, as e.g. "Windows" or "MacOSX" could also
be returned).
Use the existing DesktopType enum class instead of strings
to avoid one potential of errors, move its header from
being vcl-internal to a global vcl header and add a few
enum values for those cases that didn't have any yet.
This should e.g. prevent issues like the one detected
and fixed in previous commit
Change-Id: I9cd5076a3eeca8b8c02a121add8dd1cec18c77a8
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Mar 13 22:39:40 2026 +0100
gtk: Fix desktop environment strings in comparison
"tde" is no longer used and KDE Plasma environments
are identified by "PLASMA5" and "PLASMA6", respectively,
see SalGetDesktopEnvironment.
from happening again in the future.
Change-Id: Ifab1d67f4fa3e9150e4eb3449b3fed54e8e53b98
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201687
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
...instead of using the default -static-libsan, where dynamic libraries must be
built without -z defs and where all executables must link against the static
libsan. Dropping the latter requirement means that we no longer need the static
sal hack in Library_jpipe.
But instead, at runtime, when a process loads any library that links against the
dynamic libsan, then that dynamic libsan must be loaded first into the process.
For executables that are themselves linked against the dynamic libsan, that is
already the case. For scenarios where we invoke a Java executable, we now use
LD_PRELOAD to fulfil that requirement. (And for invocation of Python
executables, this commit assumes a --enable-python=fully-internal configuration,
so that executable will be itself linked against the dynamic libsan.)
Dropping the requirement to build without -z defs revealed that using
-fsanitize=vptr often requires RTTI symbols from libraries that are not usually
linked against. Such cases are now handled by conditionally including those
libraries in gb_*_use_libraries calls. (This could be restricted even further
to only be done under -shared-libsan, but it arguably doesn't hurt to also do it
under the default -static-libsan.)
The expectation is that -shared-libsan will explicitly be passed into the
configuration along with any other -fsanitize... arguments via
--with-extra-cc-flags and --with-extra-cxx-flags. This commit does not yet
remove the code that is only needed for the (default) -static-libsan caes, but
that code could eventually be cleaned up, once all (Clang) builds using
sanitizers use -shared-libsan. (GCC already defaults to a shared model.
Instead of a combined -shared-libsan, it has individual -shared-libasan etc.,
though. This commit does not intend to make any changes to any potential GCC
sanitizer builds; my assumption is that we do not have any such, and that they
wouldn't work out of the box, neither before nor after this change.)
Change-Id: I932e4b75c299c158211e122adf33d7988892a87e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200935
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
1. Avoid explicitly specifying COM_QUERY in calls to QueryInterface
(it is implied from the name).
2. Drop redundant ctor and set() that duplicate QueryInterface.
3. Allow ThrowIfFailed without a message.
Change-Id: I75b545e534efb7e57da131dfd40a2a49d204efac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198033
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
The following commits introduced these:
77a39107b1 (Silence clang-cl -Wextra-tokens
in midl-generated code, 2015-11-28);
5ccdc4187b (Silence clang-cl -Wextra-tokens
in midl-generated code, 2015-11-30);
34604446fc (Various clang-cl/loplugin
warnings, 2017-03-14).
The problem was, that some versions of midl compiler generated an invalid
code like "#endif !_MIDL_USE_GUIDDEF_", which caused warnings in gcc and
clang (see e.g. https://stackoverflow.com/q/29153518/1397376).
I see that as of VS 2022, this problem is not reproducible, so let's drop
these.
Change-Id: Icce797ae6fa8b1aca17ca0b5051e2af606126bf8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194010
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
...so that it can reference the JS `window` object (e.g., when clicking on "Help
- About LibreOffice - Credits")
Change-Id: Ia08226af7bbf5a503be9e0b81c27217ad2775269
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185801
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
those were from a time where there was 64bit Windows, but no 64bit
builds of LibreOffice/OpenOffice.org - now the only usecase for 32bit
LibreOffice is to use it on 32bit-only machines…
Change-Id: Icf1eacafd9e157788e8ec5a035716327492f5c2c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185565
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
The "EnableATToolSupport" setting/property that
can be queried from desktop backend implementations
doesn't seem to be used anywhere, so drop it.
There is still MiscSettings::GetEnableATToolSupport,
but that doesn't make use of the above.
Change-Id: I1ce64101d9795356e87e29c598dde25579a73111
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185071
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The DesktopEnvironmentContext class's only purpose
seems to have been to provide the name of the current
desktop environment (by using Application::GetDesktopEnvironment)
when queried for "system.desktop-environment".
Stop using this and wrapping the original context
in `InitVCL`, but instead call Application::GetDesktopEnvironment
directly in those places that were previously using the property.
The
// Desktop Environment context (to be able to get value of "system.desktop-environment" as soon as possible)
comment in InitVCL removed with this commit doesn't explain
why this "system.desktop-environment" was used in the first place
instead of calling Application::GetDesktopEnvironment directly.
(Since the implementation would call the latter, it
wouldn't be able to provide anything earlier than if calling
the method directly.)
As expected, the value for the desktop environment is the same in
both places with this commit in place as it was previously
("PLASMA6" in a KDE Plasma 6 session).
Change-Id: I37bef5d1acdf4c532265696a9f2c37f4e507b86c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185070
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
1. Drop obsolete #ifndef DONT_HAVE_GDIPLUS, introduced in commit
06c8108fe5 (Attempt to make this
build with MinGW, 2011-06-24).
2. Improve API methods implementations.
2.1. In IUnknown::Release, make sure to check the value returned
from decrement, not the member (that could potentially be modified
in the meantime again).
2.2. In ISequentialStream::Read, don't return S_OK for too large
read; and make sure to set pcbRead even on zero-byte read.
2.3. In IStream::Seek, check dwOrigin value; handle STREAM_SEEK_END
correctly, without subtracting an extra 1; don't fail on too large
positive offset (that is explicitly documented as OK); and don't
ignore the plibNewPosition argument (callers expect the new offset
there).
2.4. In IStream::Stat, check grfStatFlag value; handle OOM; don't
limit the returned offset to 32 bits.
3. Make StreamOnZipBuffer own the buffer. It user a reference to
temporaries; but the object is refcounted, and when passed to an
API, it could potentially outlive the temporaries it depended on.
4. Move CThumbviewer definition to CXX, and simplify the HXX.
Change-Id: I5b31a8bf66651862d730cc346948dc04f984fddb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/184807
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Previously, WindowsErrorString and WindowsErrorStringFromHRESULT were
defined in an anonymous namespace in windowserrorstring.hxx, which:
1. Made them unavailable to other translation units
2. Violate ODR by creating separate copies in each TU
3. Require workarounds to access them
Changes:
- Move functions to proper comphelper namespace
- Keep implementations inline as they're simple utilities
- Preserve all existing functionality
- Update all call sites to use comphelper:: prefix
This change enables proper use of these utilities across LibreOffice
while maintaining current behavior and performance characteristics.
Introduced in this commit:
commit 94cdcaa4d8
Author: Tor Lillqvist <tml@collabora.com>
Date: Thu Aug 13 13:22:28 2015 +0300
Add a globally usable WindowsErrorString function
Change-Id: I34df1c2b1f30c6204f107ca4792131d692203880
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183332
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
...and invoke it via `printf ... | uri-encode` rather than `echo ... |
uri-encode`, to avoid passing spurious newlines to it (which appears to have
been the reason for it not to encode newlines in the first place)
Change-Id: I26131a19f69c04b0beca8e8bab72c1dbb65300c1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178596
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Sync `fromQStringToOUString` with the `toOUString`
implementation in `vcl/inc/qt5/QtTools.hxx`, which
makes it work with Qt 6 as well.
Without this, building this with a planned upcoming
change that introduces a KF 6 desktop backend would fail
like this:
In file included from /home/user/development/git/libreoffice/shell/source/backends/kf6be/kfaccess.cxx:10:
/home/user/development/git/libreoffice/shell/source/backends/kf6be/../kf5be/kfaccess.cxx:53:60: error: non-constant-expression cannot be narrowed from type 'qsizetype' (aka 'long long') to 'sal_Int32' (aka 'int') in initializer list [-Wc++11-narrowing]
53 | return { reinterpret_cast<char16_t const*>(s.utf16()), s.size() };
| ^~~~~~~~
/home/user/development/git/libreoffice/shell/source/backends/kf6be/../kf5be/kfaccess.cxx:53:60: note: insert an explicit cast to silence this issue
53 | return { reinterpret_cast<char16_t const*>(s.utf16()), s.size() };
| ^~~~~~~~
| static_cast<sal_Int32>( )
Change-Id: Ic2b1ddcaa290379187db69b33e4a700c148650e1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168275
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
... and namespace.
This is in preparation of implementing a KF 6
backend that will reuse most of the code.
Change-Id: I0c0f499ff57dd18e7e0bc7dd838acfeffa30d88c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168274
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
…by a simple/static $(gb_CustomTarget_workdir)/foo
The build system has a lot of overly complicated leftovers from when it
was introduced and had not only deal with split repositories but also
had to coexist with another buildsystem. Along with lots of copy'n'paste
along the years the makefiles became hard to grasp for newcomers with
all our calls and evals.
As a first step to streamline that, the macros from TargetLocations that
simply prefix a static path to the argument (and similar of the same
kind) are a natural pick before simplifying the rules themselves/getting
rid of a bunch of eval statements.
Change-Id: Ia06dbbcd5d1994755a2ff05b84f72ccbc4e3cab5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167005
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
alohapeakina