| Age | Commit message (Collapse) | Author |
|---|
|
The OpenSSL 1.1.1 release is currently the only supported version
and it already has the Windows Arm64 support I was looking for.
This change also explicitly enables thread support, which Python
depends on since release 3.7, which removed the --without-threads
build option. But the explicit OPENSSL_THREADS was just added in
3.8.4, so the old no-threads build fails now and was wrong since
probably much longer.
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98435
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
(cherry picked from commit 0911b0a26356aa53bb94a1d2171f36e6c2e28749)
Change-Id: I61d94f966bc59407f213f4a81f0a49d0c05f8948
|
|
Change-Id: I4061cbac18ddf9c7f932a27bf2b54a2b1c2f9d99
|
|
Change-Id: Ia756f1fa642eeb6dcadc867cc9730732a73c11b4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108884
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
Sadly the existing arm64 assembler files in OpenSSL use a syntax that
Apple's clang doesn't accept.
And yeah, ideally we should not use either NSS or OpenSSL on macOS,
but native APIs for the functionality in question. Trying to make
everything look like Linux is a bone-headed approach.
Change-Id: Ib3f137ac73329b92e82c654d1277ee21f5f81b37
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98095
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105871
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
For whatever reason OpenSSL wants to use "masm" (ml.exe) on 32-bit
builds but "nasm" on 64-bit builds - this despite INSTALL.W32 claiming
that only nasm is "supported".
But /safeseh doesn't make sense on 64-bit anyway because there
is no "unsafe" SEH there, so just apply the patch only for 32-bit.
Change-Id: Ie32b17dfeeaf11c49ee29c3181021ffa5bd99091
|
|
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>
|
|
We can't "break symlinks after extracting tarball" because they populate
that dir during the build now. So instead cripple mklink.pl to
copy instead of link. (Configure no-symlinks simply skips the symlink
step instead of copying, so that appears useless)
Change-Id: Ib30b2c1b8b3de72511d09c478297a7a5a4bc691e
Reviewed-on: https://gerrit.libreoffice.org/21880
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
... to avoid calling C:/Windows/system32/{sort,find}.exe, if those
happen to be first in PATH.
On a Windows 7 system, the other conflicts appear to be harmless,
we don't use "more", "expand", "timeout", "whoami".
Change-Id: Iceefeb7ee6725291b04c0eba465991bb1df96b57
Reviewed-on: https://gerrit.libreoffice.org/21175
Tested-by: Jenkins <ci@libreoffice.org>
Tested-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
and de-ifdef-per-platform the patch makefile so an upgrade attempt on one
platform tests the patchs applying on all platforms
ubsan.patch.0 was effectively applied upstream while need
to add http://rt.openssl.org/Ticket/Display.html?id=3650 to build
under windows
Change-Id: Ieffd9bc3dd861a94a083d8b6b8d4117bba7f527c
Reviewed-on: https://gerrit.libreoffice.org/15183
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ic47a1b43323f84971aed9b3cdb2ec83f9e931d6a
|
|
fix windows style path separator to unix style, needed for cygwin.
Change-Id: I4de78d6901378644857c28a59467b59ef886f47b
Reviewed-on: https://gerrit.libreoffice.org/10855
Reviewed-by: Thomas Arnhold <thomas@arnhold.org>
Tested-by: Thomas Arnhold <thomas@arnhold.org>
|
|
this fixes gcc: error: unrecognized command line option '-arch'
The '-arch' option is part of Apple's extensions to GCC, and it is uncompatible
with "vanilla" GCC from FSF. Also, we're not building "universal binaries".
Change-Id: I44e7c72bbb1dd4be5ac9cdbc4f210aaccea513b4
Reviewed-on: https://gerrit.libreoffice.org/10117
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Win32 make has problems because the command line gets too long.
Change-Id: I157b7b2b61353b158b1a3f412331e54aafec206c
|
|
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: I1e0ee6aa3d136c75309c5c70011da787806efa1f
|
|
Change-Id: I00ee89f69d85010be5d3a537092349fa9eeb71c8
|
|
Change-Id: I10bf92b18ee5ad56f1b4fbee3e4008b35b822be4
Reviewed-on: https://gerrit.libreoffice.org/6547
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
|
