Age | Commit message (Collapse) | Author |
|
apparently in the past it was disabled because it did depend on glib,
and maybe also size constraints, but neither apply anymore.
Change-Id: Ic731b204cf482639e4d468512b97b5c39ddc73e6
|
|
Change-Id: Idef3015bf7b7bb5e0d984ac0b0a2163172cacc17
|
|
...to reduce unnecessary differences between instdir and instsets.
(Maybe CustomTarget_readmes could even generate the README_* directly into instdir?)
Change-Id: If243a229e6f0e401abe6708899964f7b5949cc09
|
|
Change-Id: I2b19708952dace09621724f5420dbc0e300f960c
|
|
... 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>
|
|
A few icons are still left in the folder as these are used as fallback for tango.
See industrial/README for details.
Change-Id: Iaeb672609cd57bba5707cbafbfe295bfb8c5011d
Reviewed-on: https://gerrit.libreoffice.org/19149
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
Change-Id: I4be3de970eabf00fd73b466adc15b6a84528a2d1
|
|
Change-Id: Iba0090da0591b6f9a6d74bb18ebaabef53448063
|
|
Change-Id: Ic0f9e47c2128b74deb0a948c1853afb13ae5fd1d
|
|
Change-Id: I6e023cd25a1481dd18e3a16b8756c43dde4560ce
|
|
That way we don't have to require the newest version for build just to
run tests.
Change-Id: I4f91828a13821b235004ff16a69043d6d43686c1
|
|
Change-Id: I1bdd2fcb0fc20f47ba4cbad52fccb6f4ada968ea
Reviewed-on: https://gerrit.libreoffice.org/20752
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
|
|
- 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>
|
|
Change-Id: I2e16ae2ecb5f3a2a37c795e5ee26f72fc92b25bc
|
|
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
|
|
Change-Id: Ib6219a90f36ad391d49a29e7fd12adae604ec8d1
|
|
...but, according to the 'Doesn't exist for VSE' comment, apparently rather on the
compiler version installed
Change-Id: I49a87fa55facee8ee66e2b44d7090d06fb104b89
|
|
...which doesn't support the cl PCH cmd line args yet
Change-Id: I0a5a4d6c82138992c6e40b5958a41a7fa0be88ac
|
|
Change-Id: I820ea4b3efc51a0464470a8a53d022602d635c81
|
|
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>
|
|
A leftover from commit b40b6010077f875565ce90cd995222451e37321c (ditch
gnome-vfs2 support, 2015-09-02).
Change-Id: I23f34da748a582161bb4a87d2d993a5b4b08aa1e
|
|
...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
|
|
Change-Id: I71997ca604f18601ec98acd2957882a26be38fc0
|
|
Change-Id: I5b6e928ab5a5f2bf84d50f3f0221c0585670d972
Reviewed-on: https://gerrit.libreoffice.org/20251
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Change-Id: Ibc95574848752111d36cc9b3ff13709921b67e6c
|
|
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
|
|
Change-Id: I5b4fbd8e56b20996406116732c5229fff4696650
|
|
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
|
|
"clang -E -P /dev/stdin" causes warnings "clang: warning: /dev/stdin: 'linker'
input unused" etc.
Change-Id: Ia9c18b59b92558e1d959ce31caf38eed101865d3
|
|
Avoid "test: too many arguments" when $CXX consists of multiple words.
Change-Id: I90969333b289fb83ab10b67cb8bfda158a0688cc
|
|
Change-Id: I21eb802e65c7054cfbf73a90c0d63a007829ebcf
|
|
Change-Id: Ie2f7662a4cc3955963517f265894b8f6a495ece8
Reviewed-on: https://gerrit.libreoffice.org/19991
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I71e0de9e13718c1a6cd11339aba740effa2e0476
|
|
...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>
|
|
E.g. when AC_PACKAGE_NAME contains spaces, PRODUCTNAME was set to empty.
Change-Id: Ie53ad1b770e54eeb03513fa2a7cfc2f4ebe65a2b
|
|
We don't need them in a MSVC or OS X compilation either.
Change-Id: I00181fe0a047df09bbdfcce34c07eb2ebc45a2da
|
|
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
|
|
Change-Id: I83702435e9f8e0e73d6a3ecee1e6a7a30dda52d9
Reviewed-on: https://gerrit.libreoffice.org/19886
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
...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
|
|
Change-Id: I38de1e66e93086c125c94b76ac5a724439a6fb17
Reviewed-on: https://gerrit.libreoffice.org/19810
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
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
|
|
Change-Id: If63c8b8a4d2f51426d0b7caacd14b985e53eb441
Reviewed-on: https://gerrit.libreoffice.org/19674
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
|
|
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>
|