- probably out of date
- links against Gtk2 and thus causes a GTk2 dependency in core packages
- the only serious usecase (Flash) is doomed anyway
Change-Id: I7264ab5eb04c2f4b6c31a815e45b9818209e5ae2
Reviewed-on: https://gerrit.libreoffice.org/20658
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Reviewed-by: Bryan Quigley <gquigs@gmail.com>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Don't ask.
Oh well, if you want to know: For some people, like me, Cygwin and its
Perl run into horrible trouble with the fork() emulation when building
OpenSSL. (But my Cygwin works fine for all else in the build. Go
figure.)
So I came up with a way to use prebuilt OpenSSL binaries. Not to be
used for release builds, of course (and the configury checks for
that), as long as our policy is to build all we can from sources.
Change-Id: Ic303bdf0c620c5122aca3d646fa1f0587221e70f
...but, according to the 'Doesn't exist for VSE' comment, apparently rather on the
compiler version installed
Change-Id: I49a87fa55facee8ee66e2b44d7090d06fb104b89
On Fedora 23, the check for dlopen happens to succeed with gcc -m32
-fsanitize=address, and then linking executables fails due to not
finding dlsym. Checking for dlsym results in the proper -ldl.
Change-Id: I02108c2c053e07b33848af068937f29967e7dc6a
The diff against the 379.37 release is 2500 lines, one of which
actually does anything at runtime (missing va_end()).
Change-Id: I1824e61fd4ac6c3ce28084913a2661134a03fd51
Reviewed-on: https://gerrit.libreoffice.org/20248
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Cygwin unsets the COMSPEC environment variable on some installations.
This is due to an error reported first time in 2005, but not solved.
There are no exact pattern when this happens, in this case it happened
on 2 windows 8.1 VM installations (one private one azure).
added check in configure.ac to alert the user earlier
COMSPEC is used in sal/osl to start processes and as such vital, and in
some perl scripts, therefore hardcoding to e.g. cmd32.exe (or the power
shell) is not an option.
Limited check to work only for cygwin.
Change-Id: I52bb6667c52560ed1a239ac301811605b8cddcbf
Reviewed-on: https://gerrit.libreoffice.org/20255
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
...which does not behave as expected with the given command line arguments, so
just strip "-cl.exe" (and any hard-coded command line arguments following it in
$CC, but that's probably rather harmless here). Expects that clang-cl is given
with an ".exe" extension in $CC (not assuming that and stripping "-cl" and
everything that might follow could be a bit too agressive).
Change-Id: If99f964dda1369b7d4bbb63b3d634b93c9f935a8
We don't support cross-compiling with MinGW currently, and in any case
if we ever attempt such again, in the meantime the free replacement
Win32 headers most likely have been updated to include the
SCRIPT_CONTROL::fMergeNeutralItems field, so no conditional
compilation is needed.
Change-Id: I38701d6c41c44952466c1ece7c8433abe67642be
Set the CFLAGS and LIBS for it in config_host.mk.in, and handle the
SYSTEM_GLYPHY case properly in RepositoryExternal.mk.
Change-Id: I56a7fe72b675b6dd4514bbd1739b53f5871ed36a
So don't link with it, to avoid pointlessly depending on the very new
glyphy package in Debian. Change this back once needed, after 5.1
branch-off.
Change-Id: I4e2e873858841429738e2992676a0142acc528ee
Won't ever be any "system" one on Windows, of course. And I think it
will take some time before Linux distros packages GLyphy, too.
But the main point is that I don't want to bother with building GLyphy
for anything it isn't used on anyway. (Sure, it isn't actually used on
Linux, either, but there might be somebody who wants to work on that.)
Also, there is no "include" in the GLyphy source tree.
Change-Id: I063369c92e8d4b868cc66513c9ec12aa4fc65f37
The used glyphy is not directly the upstream version. We currently use a
patched version that allows to disable the build for the demos.
Change-Id: Ic03355e1ea8fbc56e57afa4f90a55741fe9a563a
...in anticipation of building with clang-cl.exe on Windows
Change-Id: I1d723c9d3b5ca8a2bc6b27ef0189a7b053581398
Reviewed-on: https://gerrit.libreoffice.org/19928
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The GLEW headers are enough, and what we actually use in these
places. In addition to handling GL extension things in its dynamic
fashion, GLEW headers also have declarations for standard,
non-extension, OpenGL API, including xgl and wgl ones.
Most likely we don't need mesa_headers on Windows or OS X either, and
can drop them completely.
Change-Id: Ic0d8d6238c862f8fe4a74e99e95344dcbf540980
...found regression e31205f3ec1f941ab5a188bfde6329edf2acc55b
"EditUndoRemoveChars::GetStr must return a reference" and dubious code
0e23f7b0839df68d277186b4df54ba391ac3406a "Lets assume this doesn't want to
update m_pForcedPrefix->GetText() anyway" in addition to the apparent sillies
directly fixed in this commit.
Introduces HAVE_CXX11_REF_QUALIFIER.
Change-Id: I564e98254fd53c1dd9b34193d7057c59721ee24c
The goal is to avoid build breakage by pkg-config or whatever helpfully
putting default paths like -L/usr/lib64 into *_LIBS, which is entirely
useless since ld searches there anyway but may override other -L that
occur later on the command line for LO bundled externals.
On a Fedora 22 system, at least these variales were affected:
CLUCENE_LIBS FIREBIRD_LIBS KDE4_LIBS POSTGRESQL_LIB BOOST_LDFLAGS
Change-Id: Ie55f65c3ae29a125f16871d95ad8b716abf5c982
Reviewed-on: https://gerrit.libreoffice.org/19784
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
...ever since its introduction with f5aa04485c86a5753bd7af057b86336efe089fae
"Enable optionally using libc++ on OS X (when targeting 10.7 or later)"
Change-Id: I26ece69d7a00c7452cd027928c318bbf31d6284b
Any URLs using non-ASCII IDNA syntax need to be resolved to ASCII-only, as PDF
URI Action's URI needs to be "encoded in 7-bit ASCII."
Introduce URIHelper::resolveIdnaHost (svl/urihelper.hxx), which internally uses
icu::IDNA, which requires to bump the minimal --with-system-icu requirement from
4.2 to 4.6, which means ICU_RECLASSIFIED_CLOSE_PARENTHESIS is always true now.
Change-Id: I0e20d9a20ed2b869fba0cc7c969721411db590b3
Reviewed-on: https://gerrit.libreoffice.org/19669
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
Starting with MSVC 14.0 (aka VS 2015) C Runtime (CRT) was divided in
two logical parts: The VCRuntime, which contained the compiler support
functionality required for things like process startup and exception
handling, and a "stable" part that contained all of the purely library
parts of the CRT.
Previously, all of the CRT headers, sources, and libraries were
distributed as part of the Visual C++ SDK, installed in the VC
subdirectory of Visual Studio installation (generally C:\Program
Files (x86)\Microsoft Visual Studio 14.0\VC). The files for the
VCRuntime are still part of the Visual C++ SDK. The headers, sources,
and libraries are now distributed as part of a separate Universal CRT
SDK. This SDK is included with Visual Studio; it is installed to
C:\Program Files (x86)\Windows Kits\10. The debug ucrtbased.dll is
also included as part of this SDK and is installed to the system
directory.
In I0ef8cda7b initial support was added to suport VS 2015. In this
change support for universal CRT, .NET 4.6 and SDK 10 is added. UCRT
dirs are added to CFLAG, CXXFLAG and ILIB. SDK 10 include path is
added to SOLARINC. .NET Framework 4.6 was splitted from SDK 10 and
needs to be discovered separately.
Change-Id: I2c484b6b1debab0d71523385021abb8fc8e6027f
Reviewed-on: https://gerrit.libreoffice.org/16642
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Don't automatically --disable-odk (if not mentioned explicitly either
way) based on whether doxygen is found or not.
Caolán says: It's an absolute pain as a maintainer when packages do
that. You build it in some minimal build env and all is well, then
some depend changes and something else ends up in the build env and
now your package fails to build anymore, or behaves quite differently.
Change-Id: I8bc6ab6f90e6e070a37e37b5108081425e116173
Reviewed-on: https://gerrit.libreoffice.org/19324
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Seamonkey based address book driver is based on pre-compiled libraries
and is only used on Windows 32 bit. Remove it in favor of mork driver.
Given that Seamonkey based mozab driver also provides Outlook and
Outlook Express address book integration, that Windows-32-bit--only
feature is lost for now. If necessary, support for that feature could
be rewritten from scratch, in a way that would also work for Windows 64
bit.
Change-Id: Ie1c125e692598bda999767c328c9e2262a2b82af
Reviewed-on: https://gerrit.libreoffice.org/19560
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
3.5 release is needed for MSVC 14.0 (aka VS 2015) support. Python 3.5
removed build toolchain support for MSVC 2013. Because we still need
to support it, we duplicate the Python directory in externals and
copy old patches and dispatch to this directory for MSVC 2013. Once
the support for MSVC 2013 is dropped on master, this directory can be
removed again.
Change-Id: Idf7bc351239582f583ecbdb53c923cbdcf968089
Reviewed-on: https://gerrit.libreoffice.org/17352
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
and of course also for the Java part
Using build-id linker flag allows lldb to map the installed .so to the
non-stripped version on the buildhost.
Also ndk-gdb supports specifying a different package name on the
commandline, so no need for the error in configure anymore.
Change-Id: If6887a27cc8ab15ee6ab612502cacf0a22ade737
2.18 is the version available in RHEL 6 released in 2010.
Change-Id: I4cd4fc89f6b51e6f58ca72b8182f80316b1f4f88
Reviewed-on: https://gerrit.libreoffice.org/19330
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
