- fixes a very minor CVE: CVE-2017-1000254
- the Windows nmakefiles we were previously using have been
removed, so we use the *other* Windows nmake build system now
- /EHs override is pointless, default /EHsc should work fine
- the macros defined in ExternalProject are not needed any more
- curl-msvc-schannel.patch.1: drop, not needed with new makefiles
- curl-osx.patch.1: none of it applies, presumably fixed upstream
Change-Id: I15c71b9c82c31d286d935b57543a1b0216123b66
Reviewed-on: https://gerrit.libreoffice.org/43724
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Compiling against the 10.13 SDK with --with-macosx-version-min-
required set to 10.9 or 10.10 (or defaulted, meaning 10.9) causes a
compilation error now. Earlier SDKs did not catch it if you were using
connectx() even if targeting pre-10.11.
Try the approach from https://github.com/curl/curl/pull/1336/commits .
Change-Id: I7cac294931c8afa6ff26a6ca9cf4491aff249de0
For (implicit) --with-zlib, curl's configure would insist on calling pkg-config
and insist on using -lz to link against the zlib library. None of that fits
LO's --without-system-zlib option.
So make curl's configure honor any passed in ZLIB_CLFAGS/LIBS (unless --without-
zlib were explicitly specified; also, ZLIB_CLFAGS/LIBS would override any
explicitly specified --with-zlib=PATH, which could be considered an error, but
we do never explicitly specify --with-zlib=PATH in
external/curl/ExternalProject_curl.mk, anyway).
Both ZLIB_CLFAGS/LIBS are set in config_host.mk, so are always set as env vars,
so would already be visible to curl's configure. I nevertheless pass them into
curl's configure explicitly in external/curl/ExternalProject_curl.mk, to make
that more obvious.
With (implicit) --with-system-zlib, LO's configure.ac will set ZLIB_LIBS and
leave ZLIB_CFLAGS empty (and checks that zlib.h is indeed available without any
ZLIB_CLFAGS being necessary). And with --without-system-zlib, LO's configure.ac
will set both ZLIB_CFLAGS/LIBS. So curl's configure, as invoked from
external/curl/ExternalProject_curl.mk, will now always go into the newly added
case honoring any passed in ZLIB_CLFAGS/LIBS, which should thus always work out
nicely and use the same zlib settings as configured for LO itself.
(For documentation purposes, external/curl/zlib.patch.0 also contains the
changes to curl's configure.ac that are reflected in the changes to curl's
configure.)
Change-Id: Icf5eefe44a7f9beb8a43a9af381f46e5c8b98b04
Reviewed-on: https://gerrit.libreoffice.org/42032
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Only HTTP and FTP should be required.
Add --without-libpsl --disable-ares --disable-rtsp --disable-smb,
and --without-libidn was replaced with --without-libidn2.
Change-Id: Icf6afc8bff4cc7ad7a5a95b0c3f9a345a7cf67a3
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>
- fixes about a dozen CVEs
- tweak curl-7.26.0_win-proxy.patch:
there is a "checksrc" thing now in curl that fails the build with:
warning: use of strtok is banned (BANNEDFUNC)
so use strtok_s instead (which is MSVC's name for standard strtok_r)
- use Makefile.vc12 instead of Makefile.vc10
- remove strequal.obj from Makefile.vc12, it does not actually exist
Change-Id: Ie2da64980d88c72b0c902376ffc01abf97a7bc91
Reviewed-on: https://gerrit.libreoffice.org/30484
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
The option /Zc:wchar_t- prevented to use wchar_t as a built-in type
according to the C++ standard. In Visual C++ 6.0 and earlier, wchar_t
was not implemented as a built-in type, but was declared in wchar.h as
a typedef for unsigned short. Now, years later after the end of life
this outdated toolchain, there is no reason not to use native type.
The only issue could be the ABI compatibility. But on a quick look at
least, it looks like none of the mangled C++ symbols in the stable URE
interface actually depend on wchar_t.
We forgot to get rid of /Zc:wchar_t- in 5.1. Do that for LibreOffice
5.2, though.
Change-Id: I8d6b380660859efa44c83c830734978d31d756a0
Reviewed-on: https://gerrit.libreoffice.org/22589
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
without -lnssutil3, the configure check for nss fails when using
internal nss:
configure:24028: checking for SSL_VersionRangeSet in -lnss3
[…]
…/UnpackedTarball/nss/dist/out/lib/libnss3.so: undefined reference to
`NSSUTIL_ArgParseModuleSpecEx@NSSUTIL_3.21'
causing curl to build without ssl support:
SSL support: no (--with-{ssl,gnutls,nss,polarssl,cyassl,axtls,winssl,darwinssl} )
This makes gdrive and other remote file methods fail
Change-Id: I098feb10a760c2f80a474d9205d6f1e403477efd
Add --without-ca-bundle --without-ca-path options to curl configure
in Linux, to explicitly disable the hardcoded curl CA certificate
store.
If the store is not disabled, curl configure will try to find
one suitable for the Linux distro on which it's being built, leading
to possible problems when building on a Linux distro type while
targeting another Linux distro type (e.g. building on Red Hat
derivative targeting Debian derivative).
Change-Id: Id1ddf1d74e33bc66e4f7187e376d7379f5c4f36a
Reviewed-on: https://gerrit.libreoffice.org/23141
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
stage 1 of replacing usage of various checks for the windows platform
with the compiler-defined '_WIN32' macro
Change-Id: Iece73abdee530937e0737190b1aa97a46cd3075f
Reviewed-on: https://gerrit.libreoffice.org/22390
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
configure will add a dependency on librtmp.so.0 if the development
package happens to be installed.
Change-Id: I8500cc166d70763118e5054680f1f8c70942ba3f
The ../../../program/ links in the URE jar Class-Paths are a temporary kludge
(and juh.jar had lacked adaption for Mac OS X).
Change-Id: I2542d8a582866485dd61c05df3fc6b4b39a8403d
When building with Win32 make, the xcopy at the end of the build fails
with "Invalid arguments" error, which is clearly wrong, since the
arguments are exactly the same as before, and furthermore curl is not
built with GNU make at all, but with nmake! W-T-F?
Change-Id: Idc0b362202e1d14722573662bebeda0bc7070660
CERTINFO was included upstream:
commit f6c335d63f2da025a0a3efde1fe59e3bb7189b70
Author: Patrick Monnerat <pm@datasphere.ch>
Date: Wed Oct 30 11:12:06 2013 +0100
NSS: support for CERTINFO feature
Change-Id: I83de2fd863f9387b83b5ebcbec70cbe6df7681d4
Reviewed-on: https://gerrit.libreoffice.org/9307
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Thomas Arnhold <thomas@arnhold.org>
Tested-by: Thomas Arnhold <thomas@arnhold.org>
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
Michael Stahl