No idea why we just provided the platform flags when cross-
compiling. In the curious case, where the host platform is
detected as x86_64-pc-mingw32 per default and we actually
want to override it with x86_64-pc-cygwin, we don't do a
cross compile, but must override the host platform.
But there is additional special handling needed for the omitted
cross-platform build in the special case of --host=i686-pc-cygwin
and --build=x86_64-pc-cygwin, where we deliberatly ignore cross
building; Windows is already a slow build, so try to keep this
optimization (AMD64 can execute x86 binaries).
There is the theoretical case, where the externals config.guess
would have detected something else and that "magically" even
worked, while the LO detected triplet would fail, but this
should be fixed in the external in any way.
Change-Id: Ib7a9719e0e406fe90334b7611dc3f01b51692bfa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129153
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
This allows to define the mapping once, and avoid modification in
multiple places each time a new VS version support is added
Change-Id: I93de4c9d78c3f67a0a2e157007e9d13b6f557937
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123163
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This patch changes the configure.ac, so that LibreOffice compiles
with the latest VS 2022 preview.
The option --with-visual-studio=2022 should be added to the
autogen.input, in order to use VS 2022 preview.
Change-Id: Ia1d9bbeabbbd44ffe82af3624151b69d36c0a45c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122133
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
- 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
Xisco Fauli