Age | Commit message (Collapse) | Author |
|
- configure with:
- --host=wasm64-local-emscripten
- had to make a few externals optional, so adding:
- --disable-nss
- --disable-cmis
- --disable-curl
Change-Id: I48d1c73d2675ad2e2beaf2c341578199efbd24ee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111130
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
Adds the ARM64 platform to the VC2019 MSBuild solution. This turned
out to be tricky, because - for whatever reason - diff couldn't
detect the solution file as text, so I added the whole file to
replace it. And "-a" would just generate a UTF-16 diff, which is
not applyable, so this just adds the new file and copies it.
Change-Id: I538610bed071fd45dc107f405056f23e1bff7a09
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102855
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Adds three Windows gb_* variables:
- gb_MSBUILD_CONFIG_AND_PLATFORM can be passed as msbuild flags
- gb_MSBUILD_PLATFORM maps debug / release settings
- gb_MSBUILD_CONFIG maps the CPUTYPE to the default msbuild names
and converts the users in external projects.
Change-Id: Ie9b817721180d78d104db11c44241e4b3e46bba9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102701
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Dropped patches:
- lcms2-msvc-disable-sse2.patch.1: applied to the VS2010 solution;
so actually long unused by LO.
- 0017-Upgrade-Visual-studio-2017-15.8.patch.1: not used anymore,
because the Windows build now uses the VS2019 solution.
The new external/lcms2/c++17.patch.1 explicitly disables the
register keywordin the header.
Change-Id: Icc6dd2a41d0fc94f00fc1ac7fa5bebc941c2a791
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98734
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
(where 16.4 is currently the latest version of Visual Studio 2019 available at
<https://visualstudio.microsoft.com/downloads/>), see
<https://lists.freedesktop.org/archives/libreoffice/2020-February/084575.html>
"ESC meeting minutes: 2020-02-27": "Update baseline to VS2019 on master before
7.0 [...] check what’s the current patch level, require that? [...] no
objections"
The code from 4ea0059bca6dd84f10abcf52f6d6b81c1afec397 "VS detection: Fallback
to old registry check if vswhere failed" has been removed in accordance with its
comment "The below hack does not work for VS 2019 anyway, so should be removed
when upgrading baseline.
(Changing the comment "go to Start menu, open 'Visual Studio 2017', [...]"
regarding the installation of GNU Make from source is somewhat arbitrary, but
lets stick to the tradition of bumping that version number along with any build
baseline bump.)
Change-Id: Ic4fe8a3d347aa1748377f2d3205e302bff189b79
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89699
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
|
|
See instructions in solenv/gbuild/Trace.mk . This generates a file than
can be viewed e.g. in the Chromium tracing view.
Change-Id: I5f90647c58ca729375525b6daed2d4918adc8188
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88754
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I81052f7634c7873d893d67deb79ed7bfa6dcbc44
Reviewed-on: https://gerrit.libreoffice.org/80888
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: I8e08efb549ebd52c37183a1185d6de73f2b00601
Reviewed-on: https://gerrit.libreoffice.org/64630
Reviewed-by: himajin100000 <himajin100000@gmail.com>
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
Tested-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
...which was at maximum set to GCC's -finline-limit=0 -fno-inline
(solenv/gbuild/platform/com_GCC_defs.mk). Those options were set for debug
builds "since forever", but that looks very much like cargo cult: -fno-inline
"is the default when not optimizing" anyway
(<https://gcc.gnu.org/onlinedocs/gcc-7.4.0/gcc/Optimize-Options.html>), and it
is unclear to me how -finline-limit=0 should have any impact beyond -fno-inline
(and maybe was present for ancient compilers that only supported -finline-limit
but not -fno-inline?).
Change-Id: Id6752d03b1b7ec8763defabc5720d4dd08790874
Reviewed-on: https://gerrit.libreoffice.org/66836
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Id771f1fe0d8c6702a52836f6229a944d259fed4c
Reviewed-on: https://gerrit.libreoffice.org/66424
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
... at least, that's the plan - this is harder than it appears, as the
upstream maintainer appears to have released version 2.9 at least 3
times:
- Fedora has a file evidently downloaded before Nov. 17 with SHA512 of e30ad5a9a1ab9e7aaace9431434caa19a5ff6143db46644aba971a5ee37a265b26bf738e886d766405a7eb45a9d620d67c7ab3684ace86a107cf5a76642c04a5
- Gentoo has a file evidently downloaded before Nov. 19 with SHA256 of d4ad6f8718f7f9dc8b2a3276c9f237aa3f5eccdcf98b86dedc4262d8a1e7f009
- Debian has a file evidently downloaded before Dec. 17 with SHA256 of 48c6fdf98396fa245ed86e622028caf49b96fa22f3e5734f853f806fbc8e7d20
The lcms2-2.9.tar.gz available from sourceforge currently matches the
one Debian has, so let's use it.
* 0017-Upgrade-Visual-studio-2017-15.8.patch added (fixing CVE-2018-16435)
* 0001-Added-an-extra-check-to-MLU-bounds.patch.1 removed (fixed upstream)
Change-Id: Iab8dada8f6d77d5b2da8560993380b3332bc02f6
Reviewed-on: https://gerrit.libreoffice.org/66400
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
...when workdir/UnpackedTarball/lcms2/include/lcms2.h is included from
workdir/UnpackedTarball/pdfium/core/fpdfapi/page/cpdf_colorspace.cpp
(Library_pdfium). Even with -std=gnu++17, GCC only emits a warning (that is not
promoted to an error when building external Library_pdfium) about "register",
but at least recent trunk Clang does emit an error by default. (Clang used to
have a bug by which it failed to emit any warning/error for uses of "register"
on function parameters, but that got recently fixed with
<http://llvm.org/viewvc/llvm-project?view=revision&revision=317140> "Fix missing
-Wregister warning when 'register' is applied to a function parameter", causing
an --enable-werror build failure now when building in C++17 mode with
<https://gerrit.libreoffice.org/#/c/43851/> "Build as C++17 when GCC/Clang
supports it" locally included.)
So instead of trying to further demote any warnings/errors about those uses of
"register", just patch them away for good.
Change-Id: I7c8757e654d87be710eaaafa871300656d9ee8ff
|
|
Change-Id: I9abf1742c213f47c576ffbb7dafd33087f7037e5
Reviewed-on: https://gerrit.libreoffice.org/43307
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Tardon <dtardon@redhat.com>
|
|
Change-Id: I277f30129560ea9fa76d6439a60bb191358df99d
Reviewed-on: https://gerrit.libreoffice.org/39088
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Added patch to support arm64
Change-Id: Ie5d9ea3f3bed6e8f3142f0209a0068bb698a3960
|
|
Change-Id: I4d32b7c4b2e545a8d979bc516f64cfcbf66ecd07
|
|
It's not clear to me that this is actually required, particularly why it
would be required for VS 2015 but not VS 2017, and why only for this
external and not the others that use MSBuild.exe.
Reportedly this can fail if you have an expired or not yet registered VS,
while strangely enough everything else compiles fine in that case,
so rather than try to find out how to check for that issue in configure,
avoid the problem by removing the /Upgrade.
Change-Id: I55566e109e57117f65febb91de7580667c984a54
Reviewed-on: https://gerrit.libreoffice.org/34947
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: I50a9e8b122250af445c2a1b3d0941d508e027318
Reviewed-on: https://gerrit.libreoffice.org/34528
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
|
|
...introduced with b862cbdd345ec57c2595629ded6a3969e1e65d56 "Support MSVC 15.0",
but $(filter ...,) always expands to the empty string, and this is probably what
was intended.
Change-Id: I5865ea13ba3c3d52402bcba48f4f770f6c2b8862
Reviewed-on: https://gerrit.libreoffice.org/34482
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
New compiler changes quite some stuff:
* Compiler detection done based on different registry key
* .NET SDK detection done based on different registry key
* Msbuild installation directory changed
* Merge modules installation directory changed
* SDK number in registry doesn't match the directory name:
(registry key: 10.0.14393, directory name: 10.0.14393.0)
* Compiler, include and library location directories changed
* Architecture specific directory changed: x64 instead of amd64
* Compiler own include directory must be added with -I option
* To force usage of SDK 10 (8.1 is selected per default) new
switch WindowsTargetPlatformVersion is passed to msbuild, to
avoid patching VC project files with this line:
<WindowsTargetPlatformVersion><SDK>/WindowsTargetPlatformVersion>
Known issues:
* Firebird is broken: http://paste.openstack.org/show/594333
Change-Id: I148d7932aff43bbbd07bd493504df974726234c2
Reviewed-on: https://gerrit.libreoffice.org/31279
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
|
|
In OOo times, there'd originally been efforts to allow building on Windows with
MinGW. Later, in LO times, this has been shifted to an attempt of cross-
compiling for Windows on Linux. That attempt can be considered abandoned, and
the relevant code rotting.
Due to this heritage, there are now three kinds of MinGW-specific code in LO:
* Code from the original OOo native Windows effort that is no longer relevant
for the LO cross-compilation effort, but has never been removed properly.
* Code from the original OOo native Windows effort that is re-purposed for the
LO cross-compilation effort.
* Code that has been added specifially for the LO cross-compilation effort.
All three kinds of code are removed.
(An unrelated, remaining use of MinGW is for --enable-build-unowinreg, utilizing
--with-mingw-cross-compiler, MINGWCXX, and MINGWSTRIP.)
Change-Id: I49daad8669b4cbe49fa923050c4a4a6ff7dda568
Reviewed-on: https://gerrit.libreoffice.org/34127
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I8a3b138c051d3cddf25855a635262311669bdddc
Reviewed-on: https://gerrit.libreoffice.org/33798
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Tardon <dtardon@redhat.com>
|
|
Change-Id: I9c5a442125476412435ebefea29ad1b166faab8a
|
|
...in preparation of making them orthogonal
Change-Id: If75b334c954138b3aed4f8d1ac33061a2267ad52
Reviewed-on: https://gerrit.libreoffice.org/27056
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I1a2e9d41226822934b64ad31a61c816b3163a9ed
|
|
Without explicitly specifying toolset v140, the build was
failing when only MSVC 14.0 was installed:
The builds tools for v120 (Platform Toolset = 'v120')
cannot be found
Change-Id: I6fb386d56e38cbf922de5069e70a3d3def147c0b
Reviewed-on: https://gerrit.libreoffice.org/23162
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: I3429f6a80dd7e080e8f2634ca744d1dac5ea1865
Reviewed-on: https://gerrit.libreoffice.org/21558
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: jan iversen <jani@documentfoundation.org>
|
|
Change-Id: I8848d042a008c21e407d9610161b5c67d2137a18
|
|
Change-Id: I303494f692520cdd34b88f9d5daf8a92a6b72ca2
Reviewed-on: https://gerrit.libreoffice.org/16803
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: I9e69e9d7fc8d3c0ccd393efca75be04c710fee6a
|
|
Change-Id: I0636f45bf5653ff3feabfdc2742eb767f1b84507
|
|
Change-Id: I57c49172fa5bb19968bf217285d0cd9222cc3530
|
|
Change-Id: I60701b2c0a0ec06ada24b397107b337676dbd319
Reviewed-on: https://gerrit.libreoffice.org/13229
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: I1a8ae99401e488e2ece47be4119843945154ef98
|
|
Change-Id: I2c69d9ad61137adb82213ad2a4c40e7403a395a5
|
|
Hopefully this should fix up the most important external libraries.
Change-Id: I744cb5a2ce7fafb10852059050cf24589d6ca400
|
|
...to latest versions from <http://git.savannah.gnu.org/gitweb/?p=config.git;
a=blob_plain;f=config.guess;hb=HEAD> and <http://git.savannah.gnu.org/gitweb/?
p=config.git;a=blob_plain;f=config.sub;hb=HEAD>, for aarch64 support.
Change-Id: I99756c33652aa8e19c6a407260b5c49de140128e
|
|
Easier than trying to figure out how to make the VC2010 projec work
with VS2013, it seems. We only need a project file for the lcms2_DLL
project.
Change-Id: Icab47ac7625b9a492942ea0835fe52ef06cdf2d9
|
|
Change-Id: I5ec1ea40e57c7d9de337645421be89e1e4c5a867
Reviewed-on: https://gerrit.libreoffice.org/10157
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: I4dbf663790bd8906ef8b123a01bdf52e0c0c1962
|
|
Change-Id: I40bc9e4c31e270f29cc145b5d2f3544cad586bf7
|
|
VS2012 did change return value of fileno function, this results in a
crash when run in GUI mode (but not when launching from a shell), as
python tries to access the nonexisting stdin/stdout/stderr
Also explicitly target Windows XP
Change-Id: Ic783713b55453f3c38b2e766a664b7f4678711de
|
|
Change-Id: I0d6537da5d605a011bd9b4491c472b0b58fcd668
|
|
Change-Id: Iaa5593d1593c9a54127c9019a4121af6a207d4c5
Reviewed-on: https://gerrit.libreoffice.org/9317
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Thomas Arnhold <thomas@arnhold.org>
|
|
Change-Id: I0cc43cef91e3fcd82a3558a16ab0afbd4d56b141
|
|
Change-Id: I2bc45e4ba63f5faaee7389bcd9d7b3f563503186
|
|
Deliver all external libraries to INSTDIR directly.
Change-Id: I8d3e035e5cfa07bd0f53ee4a226c48d4b86a4032
|
|
Change-Id: Ieddc80d510884eeb6f64325f9dfbb34f1d3fb0b5
|
|
Change-Id: I122a8564795f3a422d6bb10a5d6a845b72e77102
Reviewed-on: https://gerrit.libreoffice.org/6327
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
|