it is no more complex, and it saves us the construction of an
intermediate vector
Change-Id: Ie92c2970c5b10805d7bcfc0cc2a74378f2cbda08
Reviewed-on: https://gerrit.libreoffice.org/64039
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This changes how the list items are identified in the code, making
use of the support for item ids in comboboxes introduced in commit
83cefb5ceb.
Change-Id: I69390c8f9d32b77454e2935cf28b38ea44be8ffd
Reviewed-on: https://gerrit.libreoffice.org/63238
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I9ee3318c79d3b59f272a2a5f89c38b26afa05974
Reviewed-on: https://gerrit.libreoffice.org/63775
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
macOS's linker can take a -filelist argument, in place of taking the
list of object files to link on the command line. This is a more limited
version of "response files" as used elsewhere in the code base, and by
using it we make it far less likely that a linker invocation will hit
ARG_MAX.
A standard LibreOffice build probably won't hit ARG_MAX on macOS just
yet, but it's not far off - some LDFLAGS are enough to tip it over the
edge, which is what prompted me to fix the issue. If not fixed, a few
more object files will probably break LibreOffice builds on macOS! An
example of another large program that has encountered this issue is
Thunderbird, which implemented the same fix[1].
The changes I've made to use -filelist are adapted from the code
elsewhere in gbuild that creates response files, but this is slightly
different because -filelist files are a bit different - they can only
contain object files, as opposed to arbitrary linker arguments, and
arguments are separated by newlines rather than spaces.
[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=837618
Change-Id: I01b9126aad95056c3dc82f941dea4fd43f95d0f2
Reviewed-on: https://gerrit.libreoffice.org/64010
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
(*) also make it more obvious what XMLShapeExportFlags::SIZE represents
Change-Id: Ie63edf0f2827f171542037b819ebe7d55e090275
Reviewed-on: https://gerrit.libreoffice.org/63948
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Apparently import isn't always properly reading some of these
strings, so it is just garbage being round-tripped in some cases.
Let's just avoid that until such time as import might be fixed.
I couldn't readily identify the import problem. It even happens with
version eWW8 files and also TestBeltAndBraces() didn't seem to
prevent the problem.
These crashes are due to reading garbage:
/srv/crashtestdata/files/doc/ooo78311-1.doc
-DISTRICT_COURSE_OUTLINE_TEMPLATE.doc
/srv/crashtestdata/files/doc/kde79024-2.doc
-Ü2_Blanko.doc
/srv/crashtestdata/files/doc/ooo24395-1.doc
-stateapp-emp.doc
/srv/crashtestdata/files/doc/abi9921-1.doc
/srv/crashtestdata/files/doc/ooo59101-1.doc
-Hovedblankett.DOC
/srv/crashtestdata/files/doc/fdo48097-1.doc
-BR1010.doc
Change-Id: Iceaa53760867f06c73ab900c57f197dbc0fb8e65
Reviewed-on: https://gerrit.libreoffice.org/63938
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
This reverts commit 74d6476a04. Developer
Toolset 7 has apparently not yet been installed on vm139 (the node exclusively
executing this job), see
<https://ci.libreoffice.org/job/lo_callgrind_linux/6525/console>:
> checking for gcc... /opt/rh/devtoolset-7/root/usr/bin/gcc
> checking whether the C compiler works... no
> configure: error: in `/home/buildslave/lode/jenkins/workspace/lo_callgrind_linux':
> configure: error: C compiler cannot create executables
> See `config.log' for more details
> Error running configure at /home/buildslave/lode/jenkins/workspace/lo_callgrind_linux/autogen.sh line 296.
... since initial commit d791366863
V560 A part of conditional expression is always false: (nArse == 0x2225).
Change-Id: I4afb30f0c6c067d0e42e3fa15e5c2b2c1caa73b3
Reviewed-on: https://gerrit.libreoffice.org/63996
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This reverts commit 4d72f292cb. Developer
Toolset 7 has apparently not yet been installed on gandalf (the node exclusively
executing this job), see
<https://ci.libreoffice.org/job/lo_tb_random_config_linux/1623/console>:
> checking for gcc... /opt/rh/devtoolset-7/root/usr/bin/gcc
> checking whether the C compiler works... no
> configure: error: in `/lo/home/tdf/lode/jenkins/workspace/lo_tb_random_config_linux':
> configure: error: C compiler cannot create executables
> See `config.log' for more details
> Error running configure at ./autogen.sh line 296.
Enabling it in the relevant distro-configs/Jenkins/* file is more intuitive than
enabling it in autogen.sh (and avoids issues like
d057e61cb5 "Restrict Developer Toolset to
Config=linux_gcc_release_64"), and will also be used for other Jenkins jobs like
<https://gerrit.libreoffice.org/#/c/63982/> "Enabling Developer Toolset 7 for
Jenkins' lo_tb_master_linux_dbg".
Change-Id: If633044a90c35a12a73d60335839af0a106aa20f
Reviewed-on: https://gerrit.libreoffice.org/63989
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
