With this new version, the build started to fail with
error: ‘XML_Size XML_GetCurrentColumnNumber(XML_Parser)’ is deprecated: please use XML_GetCurrentColumnNumber64 instead [-Werror=deprecated-declarations]
so we need to check the expat version in case the system expat
is older than 2.9
Also add 0001-fix-XML_GE-is-not-defined-evaluates-to-0-Werror-unde.patch
to fix
error: "XML_GE" is not defined, evaluates to 0 [-Werror=undef]
1087 | # if XML_GE == 1
| ^~~~~~
cc1plus: all warnings being treated as errors
Change-Id: If4f1d652941b7766ed94b65a6eaa018f37c89387
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211867
Tested-by: Jenkins
Tested-by: René Engelhard <rene@debian.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
...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>
Replaces the memcpy() and memmove() with std::copy_n() and
std::copy_backward() in fastserializer.cxx.
Change-Id: I6d971f18d1138f03ab62a5007db5d0da63f7679a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203377
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
...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>
Since some code needs flexibility in error handling, where hardcoded
error value of -1 wasn't handy, o3tl::convertToHex was changed to
accept the error value as its template parameter.
Change-Id: Ifc771cc8fa29a801d4556dea969fc3ea7e620df5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199367
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
lcl_isLeapYear used a simple "is divisible" method to check if a given
year is leap. But that didn't take BCE into account: we use historical
numbering system, where before year 0001 was year -0001; and that year
was leap.
Use comphelper::date::getDaysInMonth for that, which is correct, and
also deduplicates the code. Make sure that years beyond sal_Int16 are
considered an error: they are not representable in css::util::Date,
and comphelper::date::getDaysInMonth takes years as sal_Int16.
Change-Id: I34f1ad4d5d03e05a7cf787f9997b04b1d705b583
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193302
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
we will need the length anyway, and in the case that its constructed
from OString then that strlen can be elided. (For the const char* case
then std::string_view[4] will compute the len)
Change-Id: Ifc06595573625cf93f07dd72ceec8a20745e12f9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182123
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
We use the same funciton all over the place, so create a common
function in o3tl and use that in all instances where we duplicated
the code.
Change-Id: I74091fbbde8c2ba8c7e4ab30194ab53e2a338e52
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180372
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Since
commit 2e25618fe7
Author: Mike Kaganski <mike.kaganski@collabora.com>
Date: Mon Jul 8 12:12:49 2024 +0500
Make convert*Angle strict
V1001 The 'fAngle' variable is assigned but is not used by the end of the function.
V1001 The 'fAngle' variable is assigned but is not used by the end of the function.
Change-Id: Ie0c9059e18518cae46854715fa7d39cc9c942549
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175933
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Previously, Converter::convertMeasure parsed measure strings and
performed unit conversion in a single call. This was appropriate, as all
such measure strings could be converted to a common unit ahead of time.
tdf#36709, however, will introduce measures that are relative to the
current font and font size. In order to perform layout, the original
measure unit must be preserved and passed along with the original value.
This change introduces Converter::convertMeasureUnit, which parses a
measure string and returns both the value and the unit. Existing unit
conversion code has been refactored to facilitate this change.
Change-Id: Ic8dfda432e1ca117ad80c05c1939ebaf43e79a9f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175937
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
ODF uses in several places data type 'angle' (18.3.1, ODF 1.3). That is
a double followed by unit identifier 'deg', 'grad' or 'rad' or a unit
less value in degrees. LO uses in the API angles in degrees, 1/10 of
degrees and 1/100 of degrees in data types 'double', 'short' and 'long'.
Without the fix LO does not interpret the units, but takes only the
number part.
Change-Id: Ib3f2a518a25199e3cf7a7a8572e169785f75c427
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169360
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
.. and draw:rotation in <draw:hatch> element.
ODF 1.1 has not specified the syntax of datatype 'angle'. Since ODF 1.2
it is specified as double with unit "deg", "grad" or "rad", or without
unit. The unit-less value is specified to be in degrees. But OOo, AOO
and all LO versions had written the value unit-less in 1/10th of a
degree in some cases.
To fix it, LibreOffic will be enabled to read units. When then the
active versions are able to read units, starting with the then actual
version, LibreOffice will write angles with unit 'deg'.
This has already be done for gradients, see tdf#89475. This patch
starts the first step to make LibreOffice able to read units for
dr3d:end-angle (UNO D3DEndAngle) and for draw:rotation (UNO
FillHatch.Angle). I have not found further cases of writing 1/10deg.
The patch still writes unit-less 1/10th of a degree for export to
ODF 1.3 and earlier. When it is time to write unit degree or when
LibreOffice supports the next ODF versions, some places need to be
adapted. They are marked.
The converter convertAngle is renamed to convert10thDegAngle() to
indicate, that it is special. The parts, which were specific to
gradients are moved to the gradients, so that it is now usable for
dr3d:angle and draw:rotation too.
I intend to write next a patch that enables LibreOffice to read angle
units for cases where LibreOffice already writes unit-less values in
degree. That is not so urgent, but to bring LibreOffice nearer to ODF,
reading angle units should be implemented nevertheless.
The file xmlbahdl.hxx is moved from xmloff/source/style to xmloff/inc
to have access to it from xmloff/source/draw.
Change-Id: I8ffc2735f8bcfefb86efa80eb05f900c32403f31
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168336
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
I had done these a while ago, when I looked into extending loplugin:ostr to do
more automatic rewriting, and these were places where I needed to do something
manually, for one reason or another, because the automatic rewriting would not
pick it up correctly.
However, I got distracted, and a wholesale automatic rewrite would still run
into cases where an _ostr/_ustr instance from a library's .rodata would still be
referenced after the library has already been dlcose'd. So I never came around
to finishing all that.
But there appears to be renewed interest in (automatic) rewritings here now, so
it probably makes sense if I share this part of my work anyway.
Change-Id: I3da9d38398e4bca373cb0000a9d34b49a36ad58a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166792
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
Most of these don't use boost themselves, nor do they need
it transitively since the use of boost::optional was removed
Change-Id: Ic9dee1c4e160b313ec5b91677b02ffdea6c5779d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164440
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Xisco Fauli