there was a system Java-WebSocket in Fedora 35, f.e. but unaware
if this is actively packaged standalone in contemporary distros,
but useful for the coverity build case.
Change-Id: Id6393dbfb1c449b75391752a8bb5e5ea4481a084
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173725
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
In line with what's done for most optional,
build-time configurable features, use a config
header `config_cups.h` that has a `ENABLE_CUPS` define,
include that header in the relevant source file and use
#if ENABLE_CUPS
for code depending on CUPS being enabled instead of defining
a macro and using
#ifdef ENABLE_CUPS
This also aligns this with the `ENABLE_CPDB` macro used
in the same source file.
Change-Id: I71a5205fd63f9fc18470afcaf808c489ff833319
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172397
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
In preparation of Biswadeep's upcoming GSoC changes (see [1])
to update the CPDB (Common Print Dialog Backends) support to the
latest version and use the CPDB C API, add a
corresponding `--enable-cpdb` autogen option
(disabled by default).
When CPDB is enabled, check for the cpdb-frontend
library, define `ENABLE_CPDB` and set the compiler
and linker flags for building the `CPDManager`
(in vcl/unx/generic/printer/cpdmgr.cxx).
Add checks for existing code using `CPDBManager`,
so it only gets used when when CPDB is actually enabled.
While the cpdb-frontend library is currently not
actually used in `CPDManager` yet (as the previous approach
tried to use some DBUs API directly), it will be in
Biswadeep's upcoming changes.
With this commit in place, an `--enable-cpdb` build
works with this additional local test change in place
to actually make use of the library:
diff --git a/vcl/unx/generic/printer/cpdmgr.cxx b/vcl/unx/generic/printer/cpdmgr.cxx
index 7dc17cede353..0c3b71d519db 100644
--- a/vcl/unx/generic/printer/cpdmgr.cxx
+++ b/vcl/unx/generic/printer/cpdmgr.cxx
@@ -22,6 +22,8 @@
#include <cstddef>
#include <unistd.h>
+#include <cpdb/cpdb-frontend.h>
+
#include <unx/cpdmgr.hxx>
#include <osl/file.h>
@@ -259,6 +261,7 @@ CPDManager* CPDManager::tryLoadCPD()
}
}
#endif
+ cpdbPrintFile(nullptr, nullptr);
return pManager;
}
[1] https://lists.freedesktop.org/archives/libreoffice/2024-May/091911.html
Change-Id: Ifc50d2cd6496346bea55c73cb703e3c2d3eb44b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168656
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Biswadeep Purkayastha <bpdps95@hotmail.com>
This reverts commit 6517ce70e50e61441484e7ee7a4be0e265020175.
Reason for revert:
<_rene__> noelgrandin: ping?
<_rene__> noelgrandin: /usr/bin/ld: /home/rene/LibreOffice/git/master/workdir/LinkTarget/StaticLibrary/libskia.a: error adding symbols: archive has no index; run ranlib to add one
<_rene__> noelgrandin: caused by your skia static library change. I think I pointed that out once already...
<_rene__> $ ld -v
<_rene__> GNU ld (GNU Binutils for Debian) 2.42
<noelgrandin> hmm, it's not an ld version issue, because I have ld 2.41
<_rene__> gcc version 13.2.0 (Debian 13.2.0-24)
<_rene__> and
<_rene__> Debian clang version 16.0.6 (27)
<_rene__> fwiw, too
<noelgrandin> is that a mergelibs build, or a regular build?
<_rene__> mergelibs
<_rene__> (the "normal" one, not =more)
<_rene__> noelgrandin: ... and LTO
<_rene__> noelgrandin: (saying because googling gives me https://github.com/mesonbuild/meson/issues/8371. and yes, .a is built with clang and the rest with gcc "of course")
<_rene__> noelgrandin: but the Linux release builds _do_ that:
<_rene__> $ grep -E "(lto|merge)" distro-configs/LibreOfficeLinux.conf
<_rene__> --enable-mergelibs
<_rene__> --enable-lto
<_rene__> $
<loircbot> LibreOffice (core) [libreoffice-7-6-7] lohmaier+LibreOffice · readlicense_oo/license/CREDITS.fodt · update credits
<noelgrandin> oh yeah, good spotting
<noelgrandin> yes, LTO is going to be a problem because skia is built with clang
Change-Id: I96c63109d2856c6e4cb22cf9ac945d4cfa9848c9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167227
Tested-by: René Engelhard <rene@debian.org>
Reviewed-by: René Engelhard <rene@debian.org>
Tested-by: Jenkins
(1) we only use it from inside vcl
(2) it exports a boatload of symbols
(3) its a performance hotspot
so lets link it inside and give the optimiser as
much room as possible.
Change-Id: If19d5556e3b45f40ef09d1e9225d12ef5f1ec32a
Change-Id: I3d5edca20f5a15e8981f17fe9fcb9a338006eaff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167273
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
This reverts commit 806b6014db796a3970332f9cefaaabf9355d0d8f.
Reverting for now, this does not work with --enable-mergelib
Change-Id: Ib44f819d0da9ed3769f76fc40b5c15ce097390a4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164872
Tested-by: René Engelhard <rene@debian.org>
Reviewed-by: René Engelhard <rene@debian.org>
Our embedded clucene by default write a random current-time
millisecond value into version fields, in an attempt to
randomise. Clearly this is not needed for our static help, and it also
prevents builds from being reproducible.
Change-Id: I011388b5bc72b5d86bc1900f5439036ede60c020
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158845
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Integrates zxcvbn-c as a static library.
zxcvbn-c is C/C++ implementation of
https://dropbox.tech/security/zxcvbn-realistic-password-strength-estimation.
This is the first step for introducing a password strength
meter. Some example projects that utilize zxcvbn-c are
KeepassXC, monero-gui.
ExternalProject_zxcvbn-c takes care of the dictionary node
generation bits resulting in the dict-src.h
Then StaticLibrary_zxcvbn-c depends on
ExternalProject_zxcvbn-c and uses the generated bits and the
zxcvbn-c source to compile the library.
It should be possible to get rid of dictionary node
generation bit with a patch that includes a constant
dict-src.h that's what monero-gui does for example. But this
might also obfuscate what dict-src.h is.
Right now the dictionary that is included with zxcvbn-c only
targets English, so that might be something to improve upon.
Change-Id: Ic2b0a558cff341114d69fbdc257979a28bf5c865
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157565
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
Reviewed-by: Sarper Akdemir <sarper.akdemir.extern@allotropia.de>
This commit includes the changes in 5e3510dbb62229cfb01da371d39ecc27b0d44880
and 219bef04b7084eef49e1001312e186f390f4f735, as well as the following changes:
* add bzip2 as permissable build target when cross compiling for Windows ARM64.
* add external/bzip2/disable-test.patch.0 for cross-compiling.
* revert the changes to configure.ac in 5e3510dbb62229cfb01da371d39ecc27b0d44880.
* change the argument of gb_UnpackedTarball_fix_end_of_line.
Change-Id: Iad8b1ed48d6c56e1302d9ac11620dc8084e79276
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157101
Tested-by: Taichi Haradaguchi <20001722@ymail.ne.jp>
Reviewed-by: Taichi Haradaguchi <20001722@ymail.ne.jp>
- FunctionBasedURPConnection is used to enable a client to open a URP
connection to a fresh Kit instance in COOL.
- This URP connector can be used with that and
https://github.com/CollaboraOnline/online/pull/6992 to use a Java Uno
Remote Protocol client over websockets
- For interoperability with existing Collabora Online websockets a
prefix (urp ) is added to each message sent and a similar prefix
(urp: ) is expected on each message recieved. This allows sending over
the same websocket as other data is being transmitted through. If you
are writing a bridge to work with this, you will need to add/strip the
prefixes accordingly
- This commit uses Java WebSocket
(https://github.com/TooTallNate/Java-WebSocket) to send data over
websockets.
Change-Id: I2bda3d0b988bef7883f9b6829eeb5b7ae8075f27
Signed-off-by: Skyler Grey <skyler.grey@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151171
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Add a "kf6" VCL plugin that uses the KF6 (KDE Frameworks 6)
libraries to provide a native KDE/Plasma file chooser,
just like the kf5 VCL plugin does for KF5.
Building the plugin is disabled by default and can be enabled by
autogen option '--enable-kf6'.
Selecting the VCL plugin can be done by starting LO
with environment variable 'SAL_USE_VCLPLUGIN=kf6' set.
The kf6 VCL plugin reuses the kf5 VCL plugin code.
(The kf6 headers and sources for now just `#include`
the kf5 ones.)
This was quickly tested on KDE Neon unstable,
which provides a daily snapshot of Plasma 6 and the KF6
libraries.
(Regarding a potential release date, [1] mentions:
"Plasma 6 is built on top of Qt 6 and is
tentatively planned to be released in late 2023 or early 2024.")
[1] https://community.kde.org/Plasma/Plasma_6
Change-Id: I4c2b7e3be8e60f1d8cf60119f6f3f642b71349f5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153438
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
...so that e.g. a from-scratch `make CppunitTest_sw_core_layout` doesn't fail
with
> warn:sal.osl:3973661:3973661:sal/osl/unx/module.cxx:103: dlopen(workdir/LinkTarget/Library/libvclbootstrapprotector.so, 257): libfontconfig-lo.so.1.12.0: cannot open shared object file: No such file or directory
> Failure instantiating protector "workdir/LinkTarget/Library/libvclbootstrapprotector.so", "vclbootstrapprotector"
(This is LINUX-only, as ExternalPackage_fontconfig has been introduced as
LINUX-only by d552b4a549d614a03aa9328e017dec27bd3ff41e "Enable opening of
downloaded fonts only in ForKit in Online": "All this is relevant for Linux
only, as Collabora Online runs on Linux.")
Change-Id: I8976726ee8080f91a0fa97d60b8f345c48cae686
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148381
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...(as I e.g. use for a max-coverage ASan build) after
e5658b209a23a17b3f89fe3eabd1e065513622f1 "WASM cairo: link static lib directly",
causing
> [LNK] Library/libvcllo.so
> clang-16: error: no such file or directory: '.../workdir/UnpackedTarball/cairo/src/.libs/libcairo.a'
> clang-16: error: no such file or directory: '.../workdir/UnpackedTarball/pixman/pixman/.libs/libpixman-1.a'
> make[1]: *** [.../vcl/Library_vcl.mk:20: .../instdir/program/libvcllo.so] Error 1
because at least on Linux external/cairo only provides dynamic libraries
Change-Id: I7a35d7f28d99664ea749be23c76e74cd5a760f62
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143422
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Because bundled cairo is only used on Android currently, and that does
static linking, this doesn't make a difference for LO build.
But it does improve the situation when linking the bundled cairo via
libtool, because libtool unhelpfully finds libcairo.la via -lcairo,
which contains an unhelpful dependency_libs that includes "-lz", which
does not exist anywhere (LO's bundled one is called libzlib.a).
Ideally GNU libtool could be told to ignore .la files, but i don't know
how.
Change-Id: Icaaa0b441e1410a297f6d61afd81e31425138955
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143392
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
This commit reverts 3749d9af3745c0eaff7239e379578e4e2af89e9d
which removes the dependency on the external library cuckoo
Without using cuckoo the same file in tdf#130795 takes
real 0m4,892s
user 0m5,298s
sys 0m0,449s
With it, it takes
real 0m4,914s
user 0m5,276s
sys 0m0,444s
pretty much the same time
Change-Id: I4cc9000ac5bf26de22bb9835283ae8d5b3230196
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138435
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
* Client code must replace uses of idlc and regmerge with uses of unoidl-write,
see the changes to odk/examples/ and ure/source/uretext/ in
40f2aee6584eafcf4cd1d95fcf1f775e5435440d "Provide unoidl-write also for the
SDK" for examples.
* The new types.rdb format is not compatible with LibreOffice < 4.1. Clients
generating extensions containing such files are advised to use appropriate
LibreOffice-minimal-version elements.
* For compatibility with old extensions, reading the legacy types.rdb format is
still supported.
* The SDK no longer ships an idl/ sub-directory containing the udkap and offapi
.idl files (as, unlike idlc, unoidl-write does not need them).
odk/config/cfgWin.js had to be adapted to look (somewhat arbitrarily) for an
examples/ sub-directory instead of idl/ when checking for "an sdk folder".
gb_UnoApi_package_idlfiles became unused and has been removed.
* The idlc and regmerge executables have been removed. Module idlc has been
removed except for idlc/test/parser/, which is also used by
CustomTarget_unoidl/unoidl-write_test, and which may eventually be moved into
module unoidl. Module external/ucpp and the corresponding configure options
have also been removed.
Change-Id: I42a0231699b863b5ebe2bee63bc32c8f79278cc1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122363
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...in RepositoryExternal.mk and external/python3/ExternalPackage_python3.mk.
The variance in trailing slash had caused
<https://gerrit.libreoffice.org/c/core/+/130355> "external/python3: Explicitly
check that all extension modules got built" to fail on Windows at
<https://ci.libreoffice.org/job/gerrit_windows/120651/> with
> Error: missing PCbuild/win32_asyncio_d.pyd
> make[1]: *** [C:/cygwin64/home/tdf/lode/jenkins/workspace/gerrit_windows/external/python3/ExternalProject_python3.mk:37: C:/cygwin64/home/tdf/lode/jenkins/workspace/gerrit_windows/workdir/ExternalProject/python3/build] Error 1
(and note the missing slash in "PCbuild/win32_asyncio_d.pyd").
(Ideally, these two definitions would be consolidated anyway, but that's left
for later.)
Change-Id: If2e6081e966bf3931eb0092616705521b4cfd3ce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130410
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This header-only library is accurate in decimal representation of
doubles; provides API that allows to create custom representation
- so it's possible to use custom decimal separators and grouping.
This allows to unify all corner cases: integers, numbers close to
DBL_MAX, up-rounding to the next decade.
Note that Dragonbox creates the shortest decimal representation
of the number, that is unambiguously convertible back to the same
number; thus it may hide trailing digits that are unneeded for
such conversion.
The functional changes are minimal, and beneficial:
1. Rounding numbers close to DBL_MAX now takes into account the
bEraseTrailingDecZeros argument, as it should, allowing to have
"1.8E+308" for rounding DBL_MAX to 2 decimals without trailing
zeroes, instead of previous "1.80E+308".
2. Incorrect rounding is fixed in some cases, e.g. 9.9999999999999929
rounded to 10 previously using rtl_math_DecimalPlaces_Max.
3. Representing the number in the shortest way may change display
of some printed numbers. E.g., 5th greatest double is represented
as "1.797693134862315E+308" instead of a bit longer, but giving
the same double on roundtrip, "1.7976931348623149E+308". This would
generally look better for some numbers similar to the famous 0.1,
where users would likely expect more "round" representation where
it's unambiguous (but we still truncate to 15 significant decimals
anyway - so there's no point in pretending to provide exact digits
for actual binary representation).
These are reflected in the unit tests affected by the change.
Change-Id: I05e20274a30eec499593ee3e9ec070e1269232a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129948
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This commit implements a WebP reader and writer for both lossless
and lossy WebP, export dialog options for selecting lossless/lossy
and quality for lossy, and various internal support for the format.
Since writing WebP to e.g. ODT documents would make those images
unreadable by previous versions with no WebP support, support
for that is explicitly disabled in GraphicFilter, to be enabled
somewhen later.
Change-Id: I9b10f6da6faa78a0bb74415a92e9f163c14685f7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128920
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
commit 5801b9fc65508391e130670f79a9af51f18d4e96
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Jan 27 08:17:54 2022 +0000
Fix gtk3_kde5 build when qt5/kf5 VCL plugins are not built
was missing the spaces for the 'filter' function, resulting
in an '--enable-kf5 --enable-gtk3-kde5' build failing because
"TRUETRUE" doesn't match "TRUE".
Change-Id: I6dca8fb4cd9f58077ce08f51e003f3539f368f77
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129047
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Since
commit 894450d6ebbb2d5e063d72b971580d1b8c10a5e3
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Tue Sep 28 08:36:44 2021 +0200
Unify how Qt/KF build flags/libs are set
the qt5/kf5 externals are used to set includes and
compiler/linker flags for the gtk3_kde5 VCL plugin
as well.
However, the relevant link targets were only actually
defined as needed when building the qt5 and kf5 VCL plugins
was enabled as well.
Adapt that so that building the gtk3_kde5 VCL plugin
but not the qt5 and kf5 ones also works again
(e.g. '--enable-gtk3-kde5 --disable-qt5 --disable-kf5').
Change-Id: I65b75d7c2ccab71eade01aa2529fb45174056701
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129022
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
... resulting in a stripped-down, Writer-only build to decrease
the resulting WASM bytecode size.
It removes the following code from the build:
* All other major modules: Base, Calc, Chart, Draw, Impress and
Math and related writerperfect filters
* The premultiply tables
* The (auto-)recovery functionality
* All accessibility (but not the accessibility document checker)
* The LanguageGuess component
* EPUB support
* The start center / BackingWindow
* The TipOfTheDay functionality
* The splash screen communication
Currently crashs with anything different then soffice --writer.
Closing the document also still crashes.
FYI: many of these features are now behind ENABLE_WASM_STRIP_*
defines, but they normally don't work on their own, globally!
That's because we started with stripping the main components.
Change-Id: Ib9c0f9452815910c0a2aceaf142ba1ad4a9cb0d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126182
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
We probably want to pre-create the fontconfig cache in the image.
Startup time still is not really worse for me, but YMMV.
Change-Id: I419682339dd6d943753de9043ff82f2fb877b168
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128624
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Drop Build prefix and settle on Lib and Exe prefixes. Also add a
note about the "else" part of the condition and fix offenders.
While at it, define COND_LIB_SAL_TEXTENC to be used by sal to
prevent diverting coditions in build and cxx code.
Change-Id: I944587ca1ccbe46b765d1a631a7214c8126fe951
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128136
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
The include is set explicitly in RepositoryExternal.mk . And
when using system cuckoo, it's not necessary to refer to the
unpacked tarball location.
Change-Id: Idd241f7551fb98cb5948c4e7007204ad3a8d87a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128061
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Instead of always testing for DISABLE_GUI, just disable the epoxy
test and handle !ENABLE_EPOXY in RepositoryExternal.mk.
Change-Id: I38213ffa77353bc93f32caa1b4164c5fa88170ac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127999
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
...that were left behind by 023ebf17898db4bca63129f079fd90b5cf76c1a9 "ucb:
remove --with-webdav=neon"
Change-Id: I617ca74d1c4b46d8f0b9dac317b5972bfb911813
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127986
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
