| Age | Commit message (Collapse) | Author |
|---|
|
Add pvio_npipe + pvio_shmem + dialog
Change-Id: I48d828e5cdf8d269aef3a40d75235a9519af8dc1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105804
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
The main idea is to get rid of the "unset MAKEFLAGS". AFAI can
see, the whole CPU stuff isn't used anymore. So we can drop the
whole FB_CPU_ARG handling. Since LO doesn't use any of make's
implicit rules, the build breaks, but luckily it just requires a
single rule for the btyacc build - just a Firebuild build tool.
Then there is the whole broken handling of LIBTOMMATH and
LIBATOMIC_OPS already in LO's configure.ac. I don't know if any
internal build of Firebird with these as system libs would work.
I guess people either have a system Firebird or also build with
internal libtommath and libatomic_ops. This fixes just the
obvious errors. I didn't try to build it, so there might still
be typos (TBH I thought hard about just dropping the system
build of these libraries, after seeing the broken configure.ac).
And I'm not sure our / the system boost preprocessor library is
ever used over the Firebird-internal copy. It also looks like
it's also just used in an other build tool and nothing of the
Firebird DB itself depends on it.
Then there is the movement of the install_name_tool / otool
patching on MacOS from the patch into the ExternalProject to
further shrink the patches, as the build doesn't depend on it.
This also introduces a different debug build mode for the
gcc-/g++-wrapper: MSVC_USE_INDIVIDUAL_PDBS.
It uses -Fd to write a separate PDB per output file instead of
using -FS to use sync writes to a single PDB, which might work
around the PDB access failures seen by Jenkins for linking
executables. In theory it's also faster and should work with all
the other wrapper users, but I don't want to open that can of
additional build errors (yet), for eventually marginal gains.
Change-Id: I8d4c5d2f17def9e840a67ef1004787e8baaffa83
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105902
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: Id62a688d2ddf7493d419a00a9fd0dfc6a6f13f0c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106173
Tested-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
Change-Id: If304aa6be018442a72e284f62d7745b3cdaef536
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105668
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
...in vcl:
> [GAL] sounds
> instdir/program/gengal.bin: symbol lookup error: instdir/program/libvcllo.so: undefined symbol: _ZTI14GrContext_Base
> make[1]: *** [solenv/gbuild/Gallery.mk:56: workdir/Gallery/sounds.done] Error 1
(I didn't check what source exactly causes UBSan to require it now.)
Marking both the class and some of its members as SK_API would cause MSVC to
fail with
> error: attribute 'dllexport' cannot be applied to member of 'dllexport' class
so remove it from the class members.
Change-Id: I9f5ed397d32f1f445bfa1d70bcff494e78c16046
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106039
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...seen when e.g. building CustomTarget/i18npool/breakiterator/char_in.brk:
> rbbitblb.cpp:1405:18: runtime error: member access within misaligned address 0x627000026987 for type 'icu_68::RBBIStateTableRow', which requires 2 byte alignment
> 0x627000026987: note: pointer points here
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ^
and
> rbbitblb.cpp:1607:18: runtime error: member access within misaligned address 0x627000026ecf for type 'icu_68::RBBIStateTableRow', which requires 2 byte alignment
> 0x627000026ecf: note: pointer points here
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ^
(i.e., even though those code branches only access the byte-sized
RBBIStateTableRow8 data, they did so through a RBBIStateTableRow union pointer,
which has stronger alignment requirements)
Change-Id: I0abe5bd756758e33e495538f548e80f99460f43c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106038
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
No idea whether it works.
Change-Id: I008cf9fab56bedb2e1f33ad6a99c9cd95d7483a7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106024
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
Also made it necessary to adapt two places in libcdr and libebook
that used UBool TRUE which is gone now to use standard true
instead.
Change-Id: I1c1df3030f8b883bec6045756907ee0b78060382
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105964
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
MSVC compiler complains about 'warning C4312: "reinterpret_cast":
conversion from "unsigned long" to "HANDLE" of greater size'.
Seems like an real error, if real_handle is too small to hold the
full "HANDLE" value, returned by _beginthreadex.
Upstream strangely just fixed in master, not B3_0_Release branch.
Change-Id: I87ad263529e119f68da976245646bf8b69efd35a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105924
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: I74c19597b07e9d07ee90e4191b75787241fdd845
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105829
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
At least in my --enable-debug build,
workdir/UnpackedTarball/firebird/gen/Debug/firebird/lib originally contains
libfbclient.dylib -> libfbclient.dylib.2
libfbclient.dylib.2 -> libfbclient.dylib.3.0.0
libfbclient.dylib.3.0.0
so if we modify libfbclient.dylib with install_name_tool, it will break the
symlink and modify libfbclient.dylib but not libfbclient.dylib.3.0.0---where the
latter is what gets delivered via external/firebird/ExternalPackage_firebird.mk.
(This didn't cause any issues, though, because gb_LinkTarget__use_libfbembed in
RepositoryExternal.mk links against the modified libfbclient.dylib in workdir,
not against the delivered libfbclient.dylib.3.0.0, so e.g. Library_firebird_sdbc
did already contain the correct @loader_path/libfbclient.dylib.3.0.0 reference.
Also, the `install_name_tool -id` treatment of libEngine12.dylib in
external/firebird/firebird-macosx.patch.1 should not technically be necessary,
as nothing links against that library; but if left unmodified, it would record
the build machine's
/full-path-to/workdir/UnpackedTarball/firebird/gen/Debug/firebird/plugins/libEngine12.dylib
so better "clean it up". Also, the `install_name_tool -change` treatment of
libEngine12.dylib in external/firebird/firebird-macosx.patch.1 is necessary
because otherwise it would record a full-path dependency to
/full-path-to/workdir/UnpackedTarball/firebird/gen/Debug/firebird/lib/libfbclient.dylib.3.0.0
which macosx-change-install-names.pl, called from MAKE_POST in
external/firebird/ExternalProject_firebird.mk, would not adjust. With all those
modifications in external/firebird/firebird-macosx.patch.1, the call to
macosx-change-install-names.pl should effectively have nothing left to do, as
these libraries do not depend on any other LO-provided libraries, but better
leave it in place anyway.)
Change-Id: Icf7f2ff5cb844b07be223e0b74cd6a650725777a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105946
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I6716048f0b58eb502b9d1ade8a13b8e33e4aaf2b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105905
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
There is no /usr/lib/libz.dylib any longer in macOS 11.
No idea whether it works (especially on arm64), but that is another
issue.
Change-Id: I92ac0c500388730eca0be4766f07b1af2d2808e0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105897
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
All the needed API is already in the version we bundle, except one. And
also we'll need direct access to the underling pdfium document, for now.
Change-Id: Ib5c87c95072401b1a6ca0151177d70b4bcd8c46d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105610
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
see the linked
<https://lists.gnu.org/archive/html/autoconf/2020-11/msg00004.html> "Fallout
from _AC_UNDECLARED_WARNING in autoconf 2.70beta" for details
Change-Id: I02c0f41d8f9e2ec7f833423a55ccbfff19e5ceb8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105555
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Old make thinks that ; terminates the recipe, have to escape it.
(other changes are just cosmetic)
(regression from 8c9b8c5970a08c2ef0ccddb7a691f3731d39175a)
Change-Id: Ib0119511977bbff077f037fbb5975df9f860ae58
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105516
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Change-Id: I7552b65022b725c6e87fef61478dc6e9c4322559
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105376
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
...as now reported when building with recent trunk GCC/libstdc++ on Linux:
> In file included from WPXContentListener.cpp:26:
> In file included from ./WPXContentListener.h:29:
> ./WPXTable.h:56:31: error: unknown type name 'size_t'; did you mean 'std::size_t'?
> const WPXTableCell *getCell(size_t i, size_t j)
> ^~~~~~
> std::size_t
Change-Id: Ic20240f01c7b0305cb87ababf53a3aaf66072d61
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105324
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
(Or whatever it is that had broken it.)
Change-Id: I72bc42e618f011518c05a2cdb875cfe64515b4d2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105269
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
Change-Id: Ic10cf99fa412f8f0b3475e82d0a1839a7f04bd08
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105272
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
...seen when opening an Impress presentation on GNOME/X11:
> cairo-xlib-source.c:570:26: runtime error: left shift of 191 by 24 places cannot be represented in type 'int'
> cairo-xlib-render-compositor.c:1852:17: runtime error: left shift of negative value -186
> cairo-xlib-render-compositor.c:1853:17: runtime error: left shift of negative value -646
> cairo-xlib-surface-shm.c:1157:43: runtime error: member access within null pointer of type 'cairo_xlib_shm_surface_t' (aka 'struct _cairo_xlib_shm_surface')
> cairo-fixed-private.h:252:8: runtime error: left shift of negative value -146048
Change-Id: I93a5706c2ec3f83bc56d75fc92817668eef57fdb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105074
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
> pixman-utils.c:217:14: runtime error: left shift of 155 by 24 places cannot be represented in type 'int'
...which happened once while using the LO GUI
Change-Id: I174a29e240f09576859308ada56fe240881f0dad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104915
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
A full `make check screenshot` required lots of little "harmless" fixes in
pixman and cairo to address:
> cairo-image-compositor.c:133:34: runtime error: left shift of 255 by 24 places cannot be represented in type 'int'
during CppunitTest_emfio_emf
> pixman-fast-path.c:3089:23: runtime error: left shift of 255 by 24 places cannot be represented in type 'int'
during CppunitTest_emfio_emf
> pixman-sse2.c:5019:17: runtime error: load of misaligned address 0x7f99303dbac5 for type 'uint32_t' (aka 'unsigned int'), which requires 4 byte alignment
during CppunitTest_emfio_emf
> cairo-fixed-private.h:64:14: runtime error: left shift of negative value -8388608
during CppunitTest_emfio_wmf
> pixman-sse2.c:6443:20: runtime error: left shift of 198 by 24 places cannot be represented in type 'int'
during CppunitTest_filter_svg
> pixman-sse2.c:5976:6: runtime error: load of misaligned address 0x629000163202 for type 'uint32_t' (aka 'unsigned int'), which requires 4 byte alignment
during CppunitTest_filter_svg
> pixman-sse2.c:3259:10: runtime error: load of misaligned address 0x606000c85761 for type 'uint32_t' (aka 'unsigned int'), which requires 4 byte alignment
during CppunitTest_oox_vml
> pixman-sse2.c:521:18: runtime error: load of misaligned address 0x607000ca9d41 for type 'const uint32_t' (aka 'const unsigned int'), which requires 4 byte alignment
during CppunitTest_oox_vml
> pixman-gradient-walker.c:196:14: runtime error: left shift of 255 by 24 places cannot be represented in type 'int'
during CppunitTest_sc_tiledrendering
> pixman-combine32.c:786:1: runtime error: left shift of 255 by 24 places cannot be represented in type 'int32_t' (aka 'int')
during CppunitTest_vcl_backend_test
> pixman-fast-path.c:2761:29: runtime error: left shift of negative value -99
during CppunitTest_xmloff_draw
> pixman-bits-image.c:243:31: runtime error: left shift of negative value -99
during CppunitTest_xmloff_draw
> pixman-bits-image.c:244:31: runtime error: left shift of negative value -9
during CppunitTest_sd_tiledrendering
> pixman-fast-path.c:2762:29: runtime error: left shift of negative value -84
during CppunitTest_sw_rtfexport2
> cairo-gstate.c:2300:14: runtime error: null pointer passed as argument 1, which is declared to never be null
during CppunitTest_sw_ooxmlexport8
> pixman-access.c:389:2: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
during CppunitTest_sw_ooxmlexport15
> ERROR: AddressSanitizer: stack-use-after-scope on address 0x7ff264ae275c at pc 0x7ff238941795 bp 0x7fff6bbadb10 sp 0x7fff6bbadb08
> READ of size 4 at 0x7ff264ae275c thread T0
> #0 in _add_clipped_edge at workdir/UnpackedTarball/cairo/src/cairo-polygon.c:351:24 (instdir/program/libcairo.so.2 +0x88c794)
during CppunitTest_sw_odfexport
> cairo-tor-scan-converter.c:1619:34: runtime error: left shift of negative value -39
during CppunitTest_sw_odfexport
> ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fe6ca085750 at pc 0x000000325c3a bp 0x7fff899bedd0 sp 0x7fff899be580
> READ of size 16 at 0x7fe6ca085750 thread T0
> #0 in __asan_memcpy at /home/sbergman/github.com/llvm/llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:22:3 (workdir/LinkTarget/Executable/cppunittester +0x325c39)
during CppunitTest_sw_odfexport
> pixman-sse2.c:3352:14: runtime error: left shift of 65535 by 16 places cannot be represented in type 'int'
during CppunitTest_sw_odfexport
> cairo-gstate.c:2355:14: runtime error: null pointer passed as argument 1, which is declared to never be null
during CppunitTest_basctl_dialogs_test
> pixman-sse2.c:3537:10: runtime error: load of misaligned address 0x615000167682 for type 'uint32_t' (aka 'unsigned int'), which requires 4 byte alignment
during CppunitTest_sc_screenshots
> cairo-image-source.c:512:10: runtime error: load of misaligned address 0x6180037aee6f for type 'uint32_t' (aka 'unsigned int'), which requires 4 byte alignment
during UITest_writer_tests7
Change-Id: Icd2a211df4751d8dbfd5903bfba424b4c4672999
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104572
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
I had managed to break it with 92b99bddb63b1bf4a639fc969727ac35b3ed1ac8
that made it possible to build for (Rosettafied) x86_64 on an Apple
Silicon Mac.
Change-Id: I337f2a8e777394e586f659fadd819cf7dfc0a332
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104546
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
|
|
Change-Id: I3e596254b2e4ecc9f56ff09eeb63b66195ea6a2e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104376
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Clang's scan-build tool uses the CLANG_CXX environment variable (setting it up
in the scan-build script to pass it to the ccc-analyzer script), but happens to
erroneously set it to a non-existing path (see <https://reviews.llvm.org/D89481>
"[scan-build] Fix clang++ pathname again"). So wrapping LO's autogen.sh and
make in scan-build picked up that broken CLANG_CXX and caused build
failures like
> [CXX] external/skia/source/SkMemory_malloc.cxx
> /bin/sh: ~/llvm/inst/bin/clang-12++: No such file or directory
(see
<https://lists.freedesktop.org/archives/libreoffice/2020-October/086113.html>
"Re: llvm/clang static analyzer reports").
So rename CLANG_CXX, and for consistency also CLANG_CC and the various
CLANG_CXXFLAGS_INTRINSICS_*, by prefixing each with LO_.
Change-Id: Ib41cabe940f8bfb1997f74e865cca5725f859e07
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104383
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This extends PDFium with readon of "Border" property from the
PDF annotations and adds the API to PDFium wrapper.
Border is mostly used for border (line) width and the radius of
rounding of the border (for drawing a rounded rectangle for
example).
Change-Id: I03f189eee03155ec699b2f56ceed23e6839a3f03
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104361
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Id1a5906db87b05218b0810045c698e5ab2a09eca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104271
Tested-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
Taking a look at:
https://dev.mysql.com/doc/refman/8.0/en/caching-sha2-pluggable-authentication.html
"caching_sha2_password" is better than "sha256_password" plugin
Notice that "sha2" in "caching_sha2_password" refers, as the quoted url indicates:
'more generally to the SHA-2 class of encryption algorithms, of which 256-bit encryption is one instance'
Change-Id: Icbbe45f4f20345da2fb5a262b4d85bce3a1fecd9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104172
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
...as seen with recent GCC 11 trunk libstdc++:
> orcus_xlsx.cpp: In function ‘size_t orcus::{anonymous}::get_schema_rank(orcus::schema_t)’:
> orcus_xlsx.cpp:313:59: error: incomplete type ‘std::numeric_limits<long unsigned int>’ used in nested name specifier
> 313 | return it == rank_map.end() ? numeric_limits<size_t>::max() : it->second;
> | ^~~
etc.
Change-Id: If92cfb565ed9344b2ec1403793d7aeff8bd019ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104074
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Updates to the screen in raster mode aren't _that_ slow, in fact
it seems using SkRegion can make things slower because of manipulating
the region, but with SkIRect this could sometimes help a bit.
It also appears that StretchDIBits() that is used by the Windows
raster code doesn't work correctly if only a subset of the y-axis
range is specified, which reduces the usefulness.
Change-Id: Ia93d2b60f2c62461e4c2c81210ab1d5d652a2cfb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104047
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Ib9634d9e88d7e97a5c03ff4d8b7808c598c3b8bf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104040
Tested-by: Michael Stahl <michael.stahl@cib.de>
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Change-Id: Ib7d1fdfc8394c7356db436e5d1bf6126c164bacc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103937
Tested-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
This extends PDFium with getting InkStrokes and Vertices for
annotations, which wasn't implemented before, and adds support to
PDFium wrapper in LibreOffice.
Change-Id: I570d53038a59ab830fcd5639583c75cf8adda86c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103885
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
We had some seldom build failures on Windows, with errors like:
PermissionError: [WinError 32] The process cannot access the file
because it is being used by another process: '..../nssckmdt.h'.
This happens, because of the "." / parent shell hack. Thinking
about it again, it doesn't prevent the parent make to run in
parallel to the "." directory make. So I tried to use a terminal
match-all rule like
ifneq (,$(filter .,$(DIRS)))
%::
# empty terminal rule triggered
$(error can't happen)
endif
to stop the original parent make, but that doesn't work and the
$(error ...) is triggered.
So AFAIK I'm out of options here and have to restore the old
manual pre-dependency build variant - still much better then no
parallel build.
An alternative idea was to put the rest of the rules.mk in the
"else" of the terminal rule, to skip all normal rules, but this
still leaves out all rules from the rest of the make-files,
which might result in some hard to debug errors.
This reverts my upstream patch 15608:744881490c78.
Change-Id: I9e2e9e1ec9f35697c7853c92f60434f514cba5ab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103777
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
This uses MSVC instead of clang for this host.
Change-Id: Idf96668e00563be12a7819a1658b657673733d21
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103780
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
This replaces the previous, broken Windows ARM64 solution with a
general fix for Cygwin cross-building. The main problem is the
PATH environment, because that is colon-seperated on Cygwin, like
on Unix, so won't work with any absolute "Windows" path, which is
needed for the --with-cross-build option.
One general change is the adoption of icucross.inc. I don't know,
why that should prefer the general CURR_FULL_DIR from icudefs.mk
over the specific one in @platform_make_fragment@. That breaks
here, because it returns a cygwin unix path, which is used as
an option to compiled tools, which these won't be able to handle.
Change-Id: Ic2cf15b48801ac57ea5a8a2876ce59f2a84edfb3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103759
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Based on an upstream patch, with an additional hunk to fix the
debug build. Gets rid of a difference between Windows and other
builds.
Change-Id: I597a5cb429fb3257535d8a2ce1142f5f9f34cebe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103758
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
It had started to fail for me now with
> ~/gcc/trunk/inst/bin/g++ -DHAVE_CONFIG_H -I. -I. -O -MT CoinFinite.lo -MD -MP -MF .deps/CoinFinite.Tpo -c CoinFinite.cpp -fPIC -DPIC -o .libs/CoinFinite.o
> CoinFinite.cpp: In function 'bool CoinFinite(double)':
> CoinFinite.cpp:38:19: error: 'DBL_MAX' was not declared in this scope
> 38 | return val != DBL_MAX && val != -DBL_MAX;
> | ^~~~~~~
> CoinFinite.cpp:8:1: note: 'DBL_MAX' is defined in header '<cfloat>'; did you forget to '#include <cfloat>'?
> 7 | #include "CoinUtilsConfig.h"
> +++ |+#include <cfloat>
> 8 |
because of a missing -DCOINUTILS_BUILD. Which in turn was caused by
workdir/UnpackedTarball/coinmp/CoinUtils/configure (see
workdir/UnpackedTarball/coinmp/CoinUtils/config.log), which first tries to
determine an ac_declaration that would apparently be a suitable declaration of
`exit` without actually including <stdlib.h> in a C++ file. It settles on
> configure:3551: ~/gcc/trunk/inst/bin/g++ -c -g -O2 conftest.cc >&5
> conftest.cc:15:17: warning: 'void std::exit(int)' has not been declared within 'std'
> 15 | extern "C" void std::exit (int) throw (); using std::exit;
> | ^~~
> <built-in>: note: only here as a 'friend'
> configure:3557: $? = 0
(which generates a warning, but no error with the given g++ invocation). The
determined ac_declaration value is then included in confdefs.h, causing the
later
> configure:4014: ~/gcc/trunk/inst/bin/g++ -o conftest -O3 -pipe -DNDEBUG -pedantic-errors -Wparentheses -Wreturn-type -Wcast-qual -Wall -Wpointer-arith -Wwrite-strings -Wconversion -Wno-unknown-pragmas -Wno-long-long -DCOINUTILS_BUILD -Wl,-z,origin -Wl,-rpath,\$$ORIGIN conftest.cc >&5
> conftest.cc:15:17: error: 'void std::exit(int)' has not been declared within 'std'
> 15 | extern "C" void std::exit (int) throw (); using std::exit;
> | ^~~
> <built-in>: note: only here as a 'friend'
> configure:4020: $? = 1
> configure: failed program was:
> | /* confdefs.h. */
> |
> | #define PACKAGE_NAME "CoinUtils"
> | #define PACKAGE_TARNAME "coinutils"
> | #define PACKAGE_VERSION "2.9.11"
> | #define PACKAGE_STRING "CoinUtils 2.9.11"
> | #define PACKAGE_BUGREPORT "http://projects.coin-or.org/CoinUtils"
> | #define COINUTILS_VERSION "2.9.11"
> | #define COINUTILS_VERSION_MAJOR 2
> | #define COINUTILS_VERSION_MINOR 9
> | #define COINUTILS_VERSION_RELEASE 11
> | #define COIN_COINUTILS_VERBOSITY 0
> | #define COIN_COINUTILS_CHECKLEVEL 0
> | #ifdef __cplusplus
> | extern "C" void std::exit (int) throw (); using std::exit;
> | #endif
> | /* end confdefs.h. */
> |
> | int
> | main ()
> | {
> | int i=0; i++;
> | ;
> | return 0;
> | }
> configure:4045: WARNING: The flags CXXFLAGS="-O3 -pipe -DNDEBUG -pedantic-errors -Wparentheses -Wreturn-type -Wcast-qual -Wall -Wpointer-arith -Wwrite-strings -Wconversion -Wno-unknown-pragmas -Wno-long-long -DCOINUTILS_BUILD" do not work. I will now just try '-O', but you might want to set CXXFLAGS manually.
to fail, because its g++ invocation including -pedantic-errors turns that
> 'void std::exit(int)' has not been declared within 'std'
warning into an error.
There were similar build failures in the Cgl,
> ~/gcc/trunk/inst/bin/g++ -DHAVE_CONFIG_H -I. -I. -I~/lo/core/workdir/UnpackedTarball/coinmp/CoinUtils/src -DCOIN_HAS_CLP -O -MT ClpCholeskyDense.lo -MD -MP -MF .deps/ClpCholeskyDense.Tpo -c ClpCholeskyDense.cpp -fPIC -DPIC -o .libs/ClpCholeskyDense.o
> In file included from ClpCholeskyDense.cpp:11:
> ClpHelperFunctions.hpp:16:4: error: #error "don't have header file for math"
> 16 | # error "don't have header file for math"
> | ^~~~~
> In file included from ClpCholeskyDense.cpp:11:
> ClpHelperFunctions.hpp: In function 'double CoinSqrt(double)':
> ClpHelperFunctions.hpp:81:13: error: 'sqrt' was not declared in this scope
> 81 | return sqrt(x);
> | ^~~~
and Clp,
> ~/gcc/trunk/inst/bin/g++ -DHAVE_CONFIG_H -I. -I. -I.. -I./.. -I./../CglGomory -I~/lo/core/workdir/UnpackedTarball/coinmp/CoinUtils/src -I~/lo/core/workdir/UnpackedTarball/coinmp/Osi/src/Osi -I~/lo/core/workdir/UnpackedTarball/coinmp/CoinUtils/src -I~/lo/core/workdir/UnpackedTarball/coinmp/Clp/src/OsiClp -I~/lo/core/workdir/UnpackedTarball/coinmp/Clp/src -I~/lo/core/workdir/UnpackedTarball/coinmp/CoinUtils/src -I~/lo/core/workdir/UnpackedTarball/coinmp/Osi/src/Osi -O -MT CglLandPValidator.lo -MD -MP -MF .deps/CglLandPValidator.Tpo -c CglLandPValidator.cpp -fPIC -DPIC -o .libs/CglLandPValidator.o
> CglLandPValidator.cpp: In member function 'int LAP::Validator::cleanCut(OsiRowCut&, const double*, const OsiSolverInterface&, const CglParam&, const double*, const double*)':
> CglLandPValidator.cpp:66:22: error: 'fabs' was not declared in this scope; did you mean 'labs'?
> 66 | double val = fabs(elems[i]);
> | ^~~~
> | labs
> CglLandPValidator.cpp: In member function 'int LAP::Validator::cleanCut2(OsiRowCut&, const double*, const OsiSolverInterface&, const CglParam&, const double*, const double*)':
> CglLandPValidator.cpp:189:23: error: 'fabs' was not declared in this scope; did you mean 'labs'?
> 189 | double smallest = fabs(rhs);
> | ^~~~
> | labs
subdirectories, and which happened to get solved by the same approach of
removing problematic ac_declaration values from configure.
I am not sure what all that magic of determining that ac_declaration value is
supposed to be good for. There appears to be no trace of it in the
corresponding configure.ac sources, so it likely was automatically added by some
dated autotools (all three configure files mention "Generated by GNU
Autoconf 2.59"). At least on a cursory look, the determined ac_declaration
appears to only be used in configure itself, and not leak into the actual coinmp
build stage, so dropping the problematic ac_declaration values is hopefully
harmless. These three subdirectories were all that failed for me, but there
might still be silent issues in other subdirectories when a problematic
ac_declaration value would negatively affect other configure checks. (An
alternative approach could be to regenerate all the configure files from their
configure.ac sources with a recent autotools. But at least some of the existing
external/coinmp/*.patch* already change such configure files, which would need
to be adapted.)
Change-Id: I0a33b0f654800e8288d3ca28e26a64efc23a3f6b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103756
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
The -fmodules-codegen flag has been in Clang for quite a while, but it
officially works with PCHs only with Clang11+, and even there's
it's better to use the properly named -fpch-codegen. This also
fixes a problem with Clang9 having only -fmodules-codegen but
not the -fno-* variant, causing the build to break.
Change-Id: I9a8c979426f95e8c1f77cbeab1df64390d7243b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103677
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
I couldn't find a general solution to select the correct build path
when cross compiling for Windows Arm64, so this just adds the patch
in exactly this case, which WFM.
Change-Id: I6e53e1531048404b70dcf61eab0a7f4021076868
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102852
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: I27e87278545c1d41381b1ab8a49f6f6a07681bfb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103590
Tested-by: Jenkins
Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
|
|
Change-Id: I24c6c5a5d93a76a9fcc2213cd48beb8e5a5ca479
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103519
Tested-by: Jenkins
Reviewed-by: David Tardon <dtardon@redhat.com>
|
|
Change-Id: Ib787098b98f68185c1b3f6b414efbec36cad02dd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102332
Tested-by: David Tardon <dtardon@redhat.com>
Reviewed-by: David Tardon <dtardon@redhat.com>
|
|
... FT_Get_Var_Design_Coordinates
This is meant to help producing binaries which run on Ubuntu 16.04.
Change-Id: I7fc965c265d2ac97a6836df0829d3d4cd0cc9333
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103392
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
This is meant to help producing binaries on CentOS 7 which run on Ubuntu
16.04, when using internal cairo.
Change-Id: Ie4cd3fe707225a951ec8a5fb49a755064701dcfa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103378
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Not sure why I started to get that failure exactly now, but with
--with-latest-c++ enabling -std=c++20, builds with GCC (at least GCC 11 trunk)
on Fedora 32 now failed with
> In file included from ~/gcc/trunk/inst/include/c++/11.0.0/bits/max_size_type.h:37,
> from ~/gcc/trunk/inst/include/c++/11.0.0/bits/ranges_base.h:38,
> from ~/gcc/trunk/inst/include/c++/11.0.0/string_view:44,
> from ~/gcc/trunk/inst/include/c++/11.0.0/bits/basic_string.h:48,
> from ~/gcc/trunk/inst/include/c++/11.0.0/string:55,
> from ~/gcc/trunk/inst/include/c++/11.0.0/bits/locale_classes.h:40,
> from ~/gcc/trunk/inst/include/c++/11.0.0/bits/ios_base.h:41,
> from ~/gcc/trunk/inst/include/c++/11.0.0/streambuf:41,
> from ~/gcc/trunk/inst/include/c++/11.0.0/bits/streambuf_iterator.h:35,
> from ~/gcc/trunk/inst/include/c++/11.0.0/iterator:66,
> from ~/gcc/trunk/inst/include/c++/11.0.0/bits/ranges_algobase.h:36,
> from ~/gcc/trunk/inst/include/c++/11.0.0/bits/ranges_uninitialized.h:36,
> from ~/gcc/trunk/inst/include/c++/11.0.0/memory:69,
> from ../common/unicode/localpointer.h:45,
> from ../common/unicode/uenum.h:23,
> from ../common/unicode/ucnv.h:53,
> from unicode/ustdio.h:31,
> from ufile.cpp:32:
> ~/gcc/trunk/inst/include/c++/11.0.0/numbers:139:9: error: unable to find numeric literal operator ‘operator""Q’
> 139 | = 2.718281828459045235360287471352662498Q;
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ~/gcc/trunk/inst/include/c++/11.0.0/numbers:139:9: note: use ‘-fext-numeric-literals’ to enable more built-in suffixes
etc. But the reason to #undef __STRICT_ANSI__ (which is set by -std=c++... vs.
-std=gnu++...) in workdir/UnpackedTarball/icu/source/io/ufile.cpp appears to be
obsolete, at least on Fedora 32 <stdio.h> does declare fileno (which is a POSIX
extension) under -std=c++... just fine.
Change-Id: I3707418db56d7fe9946655ab27bf1bf8eb479a1b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103371
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
We must link nss statically, including the three dylibs that normally
are loaded at run-time, because including bare dylibs in an iOS appp
on the App Store is not OK. See
https://developer.apple.com/forums/thread/125796 .
For linking the softokn3 library statically, NSS already had code,
behind NSS_STATIC_SOFTOKEN ifdefs. Introduce two more macros:
NSS_STATIC_FREEBL for the freebl library and NSS_STATIC_PKCS11 for the
nssckbi library.
Turn off parallelism for the sub-make building nss. There seems to be
race conditions or something when running simultaneous instances of
the nsinstall.py script or the nsinstall program in nss (used when
building nss for the build platform).
When cross-compiling from macOS, use python3 to run the nsinstall.py
script, as it is Python 3.
Change-Id: Idd427b5ebf21f802b3feb0d5a3d259317ba8fc67
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103106
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103218
Tested-by: Jenkins
|
|
Change-Id: If8e965fa955aecdb9e7011bdddc690de9cad0c4d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103120
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I41a204fbc5e2c9b819fb948c5288f8d7b4195489
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103117
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
