- align with most of the rest of config_host
- rename DISABLE_OPENSSL to ENABLE_OPENSSL
- make this configurable
Change-Id: Ic3b41fcdda38db66134939f12265e0da24833d60
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114564
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
The Windows platform is called Arm64. But now that the ID for Mac
is also going to be renamed from arm64 to aarch64, this get's rid
of the arm64 as the UNO identifier and user in gbuild, just like
on all other Arm64 platforms.
Change-Id: I60a7eafd04b426f17b6e41ad9a09e6405c0d4173
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112973
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Fixes CVE-2020-25694, plus a bunch more CVE that don't look relevant.
* --with-krb5 no longer exists, neither does --disable-shared
* remove internal-zlib.patch.1:
zlib is only used by pg_* tools / contrib/pgcrypto
* remove postgresql-libs-leak.patch:
some relic from pre-gbuild times, not clear what the point is for
static libs
* remove postgresql-9.2.1-libreoffice.patch:
another dmake .mk file relic, and the win32 nmake build system was
removed
* add postgres-msvc-build.patch.1 to fix Cygwin perl and openssl
* on WNT, libpq.dll is now built, no longer static lib
Change-Id: Ic0232a28801b2f604d9f4e33d5621ae3362defaa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109640
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
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.
Change-Id: I61d94f966bc59407f213f4a81f0a49d0c05f8948
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98435
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
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>
This will be needed when building against Flatpak org.freedesktop.Sdk//19.08,
which no longer bundles krb5, so we will have a bundled libgssapi_krb5.so
at /app/lib (instead of under /usr), but which requires LDFLAGS=-L/app/lib to
be found.
Change-Id: I8767740ab0cbb02b6ae682b7f0e21ec90ea5ddd7
Reviewed-on: https://gerrit.libreoffice.org/80620
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...which is the latest 9.2.x currently listed at
<https://www.postgresql.org/ftp/source/>. 9.2.1 doesn't build against
OpenSSL 1.1 which dropped SSL_library_init (cf. <https://wiki.openssl.org/
index.php/Library_Initialization#libssl_Initialization>), and 9.2.24 apparently
has that covered. (Ran into this when trying to upgrade the LibreOffice flatpak
build to org.freedesktop.Sdk//18.08, which has OpenSSL 1.1.)
On Windows, the new tarball as-is fails with
> ..\..\port\chklocale.c(214): error C2037: left of 'lc_codepage' specifies undefined struct/union '__crt_locale_data'
because at least in Windows Kits/10/Include/10.0.17763.0/ucrt/corecrt.h
(included from Windows Kits/10/Include/10.0.17763.0/ucrt/locale.h), the relevant
definitions are now
> typedef struct __crt_locale_data_public
> {
> unsigned short const* _locale_pctype;
> _Field_range_(1, 2) int _locale_mb_cur_max;
> unsigned int _locale_lc_codepage;
> } __crt_locale_data_public;
>
> typedef struct __crt_locale_pointers
> {
> struct __crt_locale_data* locinfo;
> struct __crt_multibyte_data* mbcinfo;
> } __crt_locale_pointers;
>
> typedef __crt_locale_pointers* _locale_t;
which presumably has changed from a past state where that lc_codepage member was
directly publicly accessible.
<https://dev-www.libreoffice.org/src/postgresql-9.2.24.tar.bz2> is a copy of
<https://ftp.postgresql.org/pub/source/v9.2.24/postgresql-9.2.24.tar.bz2>;
`sha256sum postgresql-9.2.24.tar.bz2` reports the same
a754c02f7051c2f21e52f8669a421b50485afcde9a581674d6106326b189d126 as recorded in
<https://ftp.postgresql.org/pub/source/v9.2.24/postgresql-9.2.24.tar.bz2.sha256>
Change-Id: I196dd93aa03471042efba57ea639e1bb6655de98
Reviewed-on: https://gerrit.libreoffice.org/64730
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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>
The assumption that all configure variables had been normalized to
TRUE/<empty> turned out not to hold; convert a bit more in that
direction.
(regression from 4af38b099c)
Change-Id: I2127c515e8a833a07c9b26ed9d693ce5a1853fe4
Replace uses with CPUNAME instead, and get rid of the horrible
postgresql patch that worked around environment leakage.
Change-Id: I38ccabfc438360524a272901bb9332ea708e274c
Jan-Marek Glogowski