summaryrefslogtreecommitdiff
path: root/configure.ac
AgeCommit message (Collapse)AuthorFilesLines
2019-02-12Always set java bytecode / source target to 1.6 / 6Samuel Mehrbrodt1-17/+2
as our new baseline (as discussed in ESC call 2019-02-07) Change-Id: I8a22fab6a1f9a713cb55b4c5d8173c3bbcd28587 Reviewed-on: https://gerrit.libreoffice.org/67387 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2019-02-10fix commentRene Engelhard1-1/+1
LDAP support is mainly for ldapbe (LDAP configuration backend), the libpq one is just a by-product... so "in Base" is wrong Change-Id: I342e579b5a832f6a4722499da3f0f1c35f4c0a5d
2019-02-10Make LDAP support optionalAndrew Udvare1-1/+23
Change-Id: Ifbd3903494a81e7b155bf6468f6ca2c50b3370a4 Reviewed-on: https://gerrit.libreoffice.org/65958 Tested-by: Jenkins Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2019-02-05Fix typosAndrea Gelmini1-4/+4
Change-Id: Ie186b828d500b661029704f95f4c03e56d69c282 Reviewed-on: https://gerrit.libreoffice.org/67382 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-02-04make --enable-ld the default for debug builds, if availableLuboš Luňák1-43/+131
By default for clang this tries to use first lld and then gold, for gcc it just tries gold. https://lists.freedesktop.org/archives/libreoffice/2018-June/080437.html https://lists.freedesktop.org/archives/libreoffice/2018-July/080484.html Change-Id: I669a8fa7671553f0cf78ddf82c51364fcdb0891b Reviewed-on: https://gerrit.libreoffice.org/65426 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-02-04make --enable-split-debug the default for debug builds, if availableLuboš Luňák1-8/+19
Currently done only on Linux, as I'm unsure about the status on other platforms, and it seems that on Darwin the test passes successfully but later there are problems. Feel free to add your platform. https://lists.freedesktop.org/archives/libreoffice/2018-June/080437.html https://lists.freedesktop.org/archives/libreoffice/2018-July/080484.html Change-Id: I232ead45a1aff15cc738c612750ac28aedc08e83 Reviewed-on: https://gerrit.libreoffice.org/65425 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-02-04make --enable-gdb-index the default for debug builds, if supportedLuboš Luňák1-28/+50
Currently only done on Linux, I'm not sure about the status on other platforms, feel free to add your platform. https://lists.freedesktop.org/archives/libreoffice/2018-June/080437.html https://lists.freedesktop.org/archives/libreoffice/2018-July/080484.html Change-Id: I5997f54e530c8078250eb7c116cb6bd2604e7925 Reviewed-on: https://gerrit.libreoffice.org/65424 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-01-31Allow CXX_X86_BINARY to be passed into autogen.shStephan Bergmann1-2/+5
This is necessary for building with clang-cl, where $CXX_X86_BINARY needs to match $CXX (i.e., both invoke clang-cl) so that the compiler switches (which have been determined based on the nature of $CXX, i.e., are Clang-specific when $CXX is clang-cl) passed to $CXX_X86_BINARY are actually understood by it. (Building extensions/source/scanner/twain32shim.cxx failed with "cl : Command line error D8021 : invalid numeric argument '/Wendif-labels'".) For now, my local clang-cl build will just pass a suitable CXX_X86_BINARY similar to the passed CXX (but with --target=i686-pc-windows-msvc -arch:SSE instead of --target=x86_64-pc-windows-msvc) into autogen.sh. Change-Id: Id958525f97e1d16f17af49e0b0288c1018885749 Reviewed-on: https://gerrit.libreoffice.org/67228 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-01-31be more lenient wrt patched epmCaolán McNamara1-1/+1
commit c3ab3df902b9e2ad363d1eca14da8f9f7f1567bb Date: Thu Oct 14 09:53:40 2010 +0200 changed the configure.ac to require "Patched by Libreoffice", which was possibly an error Change-Id: I6f8e302baeed054f36b54f8bfb6f5cad826ee788 Reviewed-on: https://gerrit.libreoffice.org/67199 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-01-30Ensure configuration that defines math_errhandling in <cmath>Stephan Bergmann1-0/+8
...as demanded by the C++17 standard, and required in sc/source/core/tool/math.cxx. At least when building an --arch=i386 Flatpak (where CFLAGS/CXXFLAGS are passed in containing, among others, -O2), that failed when using -std=gnu++2a (instead of -std=c++2a) due to what looks like an error in glibc (cf. <https://flathub.org/builds/#/builders/22/builds/797>). ...and fix fallout in external/firebird for Linux x86 32-bit build: While GCC defines both __i386 and __i386__ (both as 1) regardless of -std=gnu++* vs. -std=c++*, it defines i386 (as 1) only for -std=gnu++*. But various places in the external/firebird sources check for i386 (among them src/common/common.h, which fails with #error Define FB_CPU for your platform if i386 is not defined). Change-Id: I7dce1961c79aeaccc82b1e2bdc350e02730d46af Reviewed-on: https://gerrit.libreoffice.org/67105 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-01-30don't require /autoconf/ to be 2.68 (also allow e.g. autoconf268)Christian Lohmaier1-1/+6
partially reverts 182f5a0f34fa45d2f74ba22eda41d4e39dca93e5 in the sense that configure still insists on autoconf 2.68, but in a way that allows to specify an already installed copy (that the libnumbertext build already picked up successfully) While there is autoconf268 package, it gets installed as autoconf268, but aclocal doesn't provide a way to use something else than "autoconf" In the spirit of "keeping it simple", no conditional check is done whether libnumbertext is actually enabled or not. Change-Id: Ice05a70ef56a4ed3428c74d15d6aeeaa54f71c0b Reviewed-on: https://gerrit.libreoffice.org/67159 Reviewed-by: Michael Stahl <Michael.Stahl@cib.de> Tested-by: Jenkins
2019-01-30Avoid CFLAGS being set by accidentStephan Bergmann1-8/+8
When no CFLAGS are passed into autogen.sh, f104b3cafee63b47a735cfdce0f05dab2eedbb91 "tdf#72987 run firebird test for little endian only for now" (introducing AC_C_BIGENDIAN before AC_PROG_CC) caused CFLAGS in config_host.mk to accidentally be set to -g -O2 (instead of being left undefined). Change-Id: I639ce74b468e7fb25a6bda97346c7f97d6b829aa Reviewed-on: https://gerrit.libreoffice.org/67125 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-01-29configure: require autoconf 2.68Michael Stahl1-1/+1
LO's own configure doesn't need it, but the ExternalProject_libnumbertext requires this version; since it's available in RHEL6 as "autoconf268", just keep it simple and require it in the top-level configure. Change-Id: I43a6ef10089363c344f06134d75f54685ed7026b Reviewed-on: https://gerrit.libreoffice.org/67002 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2019-01-28It's called libatomic_ops not libatomic-opsStephan Bergmann1-3/+3
cf. <https://github.com/ivmai/libatomic_ops/> (as mentioned in external/libatomic_ops/README) Change-Id: Ibd50ca81695cbcd73e005b0bbbd46ceb62b1e9dc Reviewed-on: https://gerrit.libreoffice.org/66912 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-01-24Drop unnecessary gb_DEBUG_CFLAGSStephan Bergmann1-26/+0
...which was at maximum set to GCC's -finline-limit=0 -fno-inline (solenv/gbuild/platform/com_GCC_defs.mk). Those options were set for debug builds "since forever", but that looks very much like cargo cult: -fno-inline "is the default when not optimizing" anyway (<https://gcc.gnu.org/onlinedocs/gcc-7.4.0/gcc/Optimize-Options.html>), and it is unclear to me how -finline-limit=0 should have any impact beyond -fno-inline (and maybe was present for ancient compilers that only supported -finline-limit but not -fno-inline?). Change-Id: Id6752d03b1b7ec8763defabc5720d4dd08790874 Reviewed-on: https://gerrit.libreoffice.org/66836 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-01-23Drop use of obsolete GCC -fno-default-inlineStephan Bergmann1-15/+0
...that is documented as: "Does nothing. Preserved for backward compatibility." ever since <https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=160384> from 2010. -fno-default-inline was the only value ever set in gb_DEBUG_CXXFLAGS, so the latter can be removed now. The use of gb_DEBUG_CXXFLAGS had accidentally already been removed from gb_LinkTarget__get_debugcxxflags with e751e24250fda31dde52b3c65ca79f86142dc789 "--enable-optimized should be orthogonal to --enable-debug/--enable-dbgutil", and that leaves gb_LinkTarget__get_debugcflags and gb_LinkTarget__get_debugcxxflags with identical definitions, so replace those two with a single gb_LinkTarget__get_debugflags. Some external modules had used only gb_DEBUG_CXXFLAGS, when this was apparently meant to be used in addition to gb_DEBUG_CFLAGS, so those uses have been changed to gb_DEBUG_CFLAGS now. Change-Id: I84ea0ab1233569b0b02ca057240a71f138352381 Reviewed-on: https://gerrit.libreoffice.org/66808 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-01-21Slience bogus -Werror=maybe-uninitializedStephan Bergmann1-0/+57
...as emitted by at least GCC 8.2 with --enable-optimized, e.g. at: > In file included from include/rtl/ustring.hxx:37, > from include/cppuhelper/factory.hxx:26, > from unoxml/source/rdf/librdf_repository.hxx:24, > from unoxml/source/rdf/librdf_repository.cxx:20: > include/rtl/string.hxx: In static member function ‘static std::shared_ptr<{anonymous}::librdf_TypeConverter::Node> {anonymous}::librdf_TypeConverter::extractNode_NoLock(const com::sun::star::uno::Reference<com::sun::star::rdf::XNode>&)’: > include/rtl/string.hxx:294:27: error: ‘*((void*)(& type)+8).rtl::OString::pData’ may be used uninitialized in this function [-Werror=maybe-uninitialized] > rtl_string_release( pData ); > ~~~~~~~~~~~~~~~~~~^~~~~~~~~ > unoxml/source/rdf/librdf_repository.cxx:2094:30: note: ‘*((void*)(& type)+8).rtl::OString::pData’ was declared here > boost::optional<OString> type; > ^~~~ This appears to be a common pattern of false positives with uses of boost::optional, common enough to disable the warning globally for affected compilers, even if there would also be useful findings by that warning (e.g., <https://gerrit.libreoffice.org/#/c/66619/> "Fix -Werror=maybe-uninitialized"). I didn't bother to file a GCC bug for the reproducer used in configure.ac, <https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=maybe-uninitialized> already shows lots of open bugs in that area, and the documentation at <https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Warning-Options.html> states that "GCC may not be able to determine when the code is correct in spite of appearing to have an error." (Clang appears to not support -Wmaybe-uninitialized at all, so exclude it from the configure.ac check, to not have the check's failure result in an unsupported -Wno-maybe-uninitialized end up on the compiler command line.) Change-Id: Ifb9ca4c342750eae54f7e1a01506101310484c7e Reviewed-on: https://gerrit.libreoffice.org/66621 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-01-17upgrade to python 3.5.6Caolán McNamara1-1/+1
Change-Id: I6cdfc50b2385c426e20ce0e9b216b18c763249b8 Reviewed-on: https://gerrit.libreoffice.org/66506 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-01-11Don't build dconf on Android and iOS.Deve1-2/+2
Without that modification, it finds dconf in linux system and then compilation fails when it tries to build configmgr/source/dconf.cxx because dconf headers are not found in Android NDK. Change-Id: I25ab7f1ce66ed491f08a526e462e00957135b0c2 Reviewed-on: https://gerrit.libreoffice.org/65987 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2019-01-11KDE5: return multilib supportAleksei Nikiforov1-0/+14
Change-Id: Id416ff399e443175b7c7d608c8a7a4bc38eeedcf Reviewed-on: https://gerrit.libreoffice.org/66145 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2019-01-07Disable removal of GPG socketdir with older gpgconf versionsSamuel Mehrbrodt1-8/+21
Change-Id: Id068f1c1b70c3db3d3a0faa5ebe7706f205fe4da Reviewed-on: https://gerrit.libreoffice.org/65932 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2019-01-07Fix warning message if Cygwin GNU Make is used.Mark Hung1-2/+2
Update url according to LODE current version (4.2.1) because the previous one does not support mkdir -p, which is used by libcdr and libqxp now. Change-Id: I7e50e46d2101a3cbd757d683f2d3550f896fc750 Reviewed-on: https://gerrit.libreoffice.org/65882 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2018-12-29Fix typoAndrea Gelmini1-1/+1
Change-Id: I41aa2f27b3e9b60c0c2e26dc3490cbeeb6247ee9 Reviewed-on: https://gerrit.libreoffice.org/65698 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2018-12-29tdf#114635: reimplement TWAIN-based scan using 32-bit shim on WindowsMike Kaganski1-0/+23
Since TWAIN is only actually available as 32-bit component on Windows, to use it in a 64-bit program, we need a 32-bit shim program that does all actual communication with TWAIN subsystem. This change reimplements TWAIN implementation to be a separate 32-bit process. Image is transfered from the shim to main program using file mapping API. This reverts most of commit 585d9806961342e95f7318fb947bd31e9f86dee0. 64-bit LibreOffice doesn't bundle TWAIN DSM library now. TWAIN DSM source code is still used for TWAIN headers. Change-Id: I46f178ad36acd97a9eff156624b99036fcbb83f8 Reviewed-on: https://gerrit.libreoffice.org/65688 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2018-12-27Two branches are identicalMike Kaganski1-8/+2
Change-Id: I122ff47df8c91f9a526c6bc0842598108a2cb9a7 Reviewed-on: https://gerrit.libreoffice.org/65642 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2018-12-18No more need to generate lo.xcent from lo.xcent.inStephan Bergmann1-2/+0
...after fd34a19b4d8ccbd8740cf6056be87b8c267caaec "Seems that we don't need the com.apple.application-identifier after all" dropped the last @...@ replacement there Change-Id: Id6f4d1065b28be12e5d727bab553daa17fc4dfcb Reviewed-on: https://gerrit.libreoffice.org/65275 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-17kde5: remove older kde/tde plugins, and references to thatThorsten Behrens1-322/+0
KDE4 is out of maintenance upstream since Nov. 2014, and binaries provided by TDF have switched to KDE5 as the official backend. Change-Id: I165465b56d3ba3a18912b203c06ae8fc6111c0c9 Reviewed-on: https://gerrit.libreoffice.org/60014 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2018-12-13Introduce --enable-android-editingStephan Bergmann1-0/+10
...to select the experimental ...Editing... Android build variant. (Ignored for non-Android builds, but using libo_FUZZ_ARG_ENABLE anyway, just in case.) Change-Id: I670925ff358039e38edc29db69f48a78d484f133 Reviewed-on: https://gerrit.libreoffice.org/65077 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-13Switch Android armeabi-v7a to libc++/libc++abi/libunwind tooStephan Bergmann1-8/+0
It had been left out in 4082a18406c18af7b4fcef7bd501c3679c3be56b "android: use unified headers and llvm-c++ STL (x86) with NDK 16" because "arm unfortunately crashes with llvm-c++, so keep with gnustl for now/fix that later". Making armeabi-v7a work with libc++ etc. required a number of changes, listed below, in this commit and in preceding ones. At least 32-bit x86 already worked with libc++ etc. prior to these changes in view mode, though it crashed in the experimental editing mode (enabled with strippedUIEditing in android/soruce/Makefile) as soon as one types in something, But it is not entirely clear to me why 32-bit x86 view mode didn't also fail similar to how I saw armeabi-v7a fail. (On 32-bit x86, these changes appear to neither improve nor worsen the current state, view mode still appears to work fine while editing still crashes upon typing anything. With these changes, editing mode on armeabi-v7a appears to work fine. But I tested armeabi-v7a only with a real device and 32-bit x86 only with an emulator, in case that might make a difference.) * Preceding <https://gerrit.libreoffice.org/#/c/64964/> "Move NSSLIBS to a more sensible place on the linker command line" plus this change's addition of -lunwind to the liblo-native-code.so linker command line make sure that liblo-native-code.so uses _Unwind_* functions from libunwind.a, instead of erroneously picking up the ones from libgcc.a that happen to be included in NSSLIB's nspr4 (-lgcc is automatically added to the end of the linker command line by the invoking compiler, that's how libgcc.a's _Unwind_* end up in NSSLIB's nspr4; it is neither clear to me why NSSLIB's nspr4, being a pure C library, uses _Unwind_* functions, nor why exception handling in liblo-native-code.so fails when using _Unwind_* functions from libgcc.a instead of from libunwind on armeabi-v7a, nor why that would work on 32-bit x86, but that's what I observed: ModuleManager::identify (framework/source/services/modulemanager.cxx) throws a css::lang::IllegalArgumentException, which calls __cxa_throw -> _Unwind_RaiseException, which ultimately lead to odd misbehavior and std::abort during stack unwinding when using _Unwind_RaiseException from libgcc.a instead of from libunwind). (There is no libunwind.* in android-ndk-r16b for 32-bit x86 at least, so is presumably using _Unwind_* functions from libgcc.a. It doesn't appear to make a difference if it indirectly uses those _Unwind_* functions from NSSLIB's nspr4, or directly from libgcc.a included in liblo-native-code.so if the $(if $(filter armeabi-v7a,$(ANDROID_APP_ABI)),-lunwind) had a ",-lgcc" else branch.) * Preceding <https://gerrit.libreoffice.org/#/c/64965/> "Export RTTI symbols from liblo-native-code.so, for binary UNO bridge" makes sure that excpetions thrown from the binary UNO bridge can be caught by compiled catch clauses. Not sure why the corresponding state of bridges/source/cpp_uno/gcc3_linux_intel shouldn't have run into the same issue. * Preceding <https://gerrit.libreoffice.org/#/c/64966/> "Adapt gcc3_linux_arm __cxa_exception to NDK 18 libc++abi" makes sure that our version of __cxa_exception matches the version from libc++abi. This is clearly not relevant for 32-bit x86. (The comment there android-ndk-r18b, but the additional member is already present in android-ndk-r16b/sources/cxx-stl/llvm-libc++abi/src/cxa_exception.hpp, too.) The remainder of this change just drops old armeabi-v7a--specific workarounds that are no longer needed/no longer work. Change-Id: Ief4c2d562c5032abe6c3b94ca3b3394be6fcd4d3 Reviewed-on: https://gerrit.libreoffice.org/64973 Tested-by: Stephan Bergmann <sbergman@redhat.com> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-11tdf#121925 test for URLClassPath.ClassPathURLCheckJan-Marek Glogowski1-0/+52
Adds a configure test to check for the enabled ClassPathURLCheck. Should be reverted, if our jars pass it. Change-Id: I040b41f329ccae21b92118fd58270682e50e95c1 Reviewed-on: https://gerrit.libreoffice.org/64709 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-08cross-compiling: no need for gtk or gstreamer for BUILDChristian Lohmaier1-0/+3
Change-Id: I34d2078e13119291efde85636d7c62555f10a55f
2018-12-08HAVE_CPP_ATTRIBUTE_NODISCARD is always true nowStephan Bergmann1-5/+4
...but for safety, leave the configure.ac check in for some longer. Also, save removing now-redundant SAL_WARN_UNUSED_RESULT in internal code for a follow-up commit. Change-Id: Ibe30b51c5cc4abc270f955c7c40b59f268986672 Reviewed-on: https://gerrit.libreoffice.org/64771 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-07HAVE_CXX_CWG1579_FIX is always true nowStephan Bergmann1-5/+4
...(according to <http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579> it is fixed in C++14), but for safety, leave the configure.ac check in for some longer. Change-Id: Ibd2f0cac228117e35ac299e2fe74207394c900cd Reviewed-on: https://gerrit.libreoffice.org/64773 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-07HAVE_CPP_INLINE_VARIABLES is always true nowStephan Bergmann1-5/+4
...but for safety, leave the configure.ac check in for some longer. Also remove now-redundant SAL_INLINE_VARIABLE again (which was LIBO_INTERNAL_ONLY). Change-Id: Id049e0cb84b4f97f5859f1b16b867b39b448dec0 Reviewed-on: https://gerrit.libreoffice.org/64772 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-07HAVE_CPP_ATTRIBUTE_FALLTHROUGH is always true nowStephan Bergmann1-5/+4
...but for safety, leave the configure.ac check in for some longer. Also, save removing now-redundant SAL_FALLTHROUGH for a follow-up commit. Change-Id: I9bf42d237aea4c09459f28275568cf340e588607 Reviewed-on: https://gerrit.libreoffice.org/64770 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-07HAVE_CXX14_CONSTEXPR is always true nowStephan Bergmann1-6/+3
...but for safety, leave the configure.ac check in for some longer. o3tl::array_view::max_size (include/o3tl/array_view.hxx) and o3tl::basic_string_view::max_size (include/o3tl/string_view.hxx) started to produce loplugin:staticmethods warnings, which I silenced by /not/ making the functions static. Those classes are meant to be temporary drop-in replacements for standard classes (std::span slated for C++20, prev. std::array_view; and std::basic_string_view, resp.), so should have the same behavior as their standard counterparts (and making the functions static would likely cause loplugin:staticaccess warnings at call sites). Change-Id: If21674dbf02886f453ca447544e37b184df5a25e Reviewed-on: https://gerrit.libreoffice.org/64768 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-07HAVE_BROKEN_CONST_ITERATORS is always false nowStephan Bergmann1-12/+4
...but for safety, leave the configure.ac check in for some longer. Change-Id: Ife94cdfd56696edb113e32d84f563dd805e757e5 Reviewed-on: https://gerrit.libreoffice.org/64769 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-07Use correct __cplusplus value with MSVCStephan Bergmann1-1/+1
...now that /Zc:__cplusplus is available in Visual Studio 2017 version 15.7 (see <https://blogs.msdn.microsoft.com/vcblog/2018/04/09/ msvc-now-correctly-reports-__cplusplus/>). Some external projects might run into issues when picking up /Zc:__cplusplus directly with $(CXXFLAGS_CXX11) or indirectly via $(gb_CXXFLAGS) now, but that appears not to be the case. Some obsolete MSVC-specific __cplusplus checks can be removed now. (The ones in external/libebook/libebook-msvc.patch.1 pick up /Zc:__cplusplus via $(gb_CXXFLAGS) in external/libebook/ExternalProject_libebook.mk.) Change-Id: Idc6849a0000ea424522f30f61caba112fae25d40 Reviewed-on: https://gerrit.libreoffice.org/64755 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-07All supported versions of Clang and GCC support at least C++17 nowStephan Bergmann1-2/+2
Change-Id: I9130d0d1fceeb6efb1f324c99acd38eb92e67850 Reviewed-on: https://gerrit.libreoffice.org/64733 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-06--enable-python=system no longer works on macOSStephan Bergmann1-11/+3
e.g.: > [CXX] pyuno/source/module/pyuno_callable.cxx > In file included from pyuno/source/module/pyuno_callable.cxx:19: > In file included from pyuno/source/module/pyuno_impl.hxx:27: > In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7/Python.h:85: > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7/unicodeobject.h:534:5: error: ISO C++17 does not allow 'register' storage class specifier [-Wregister] > register PyObject *obj, /* Object */ > ^~~~~~~~~ (and some $enable_python=system/$_os=Darwin-specific code can thus be removed, too) Change-Id: Ic7901732c01bef9335c63dd6f0949453f5824226 Reviewed-on: https://gerrit.libreoffice.org/64732 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-06Remove obsolete GCC version checksStephan Bergmann1-2/+2
...after <https://gerrit.libreoffice.org/63951> "Bump (Linux) GCC baseline to 7.0.0". (In some cases, those checks now need to check for __clang__, which was implicitly covered in the past by Clang consistently reporting to be GCC 4.2.1.) Change-Id: I860fef8c4ca41c22a7541f0fb2d34b37d1d69bed Reviewed-on: https://gerrit.libreoffice.org/63952 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-06Bump (Linux) GCC baseline to 7.0.0Stephan Bergmann1-2/+2
...as discussed at <https://lists.freedesktop.org/archives/libreoffice/2018-November/081435.html> "minutes of ESC call ..." Change-Id: Ib1a4fdc56c51ab5c9e45173263689db2b88d72e7 Reviewed-on: https://gerrit.libreoffice.org/63951 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-06Remove broken rebuild of compilerplugins when CLANG_FULL_VERSION changedStephan Bergmann1-2/+1
Not all compilerplugins/clang/*.cxx depend on config_clang.h (e.g., check.cxx doesn't), so this mechanism trying to rebuild compilerplugins once the underlying Clang installation changes doesn't work reliably in practice (just debugged through this with Miklos on IRC, and it wasn't the first time that `make distclean` fixed compilerplugins for somebody after they upgraded their Clang installation). Removing the brittle mechanism shows that plugin.hxx doesn't actually depend on config_clang.h. (There's a second mechanism trying to rebuild compilerplugins once the underlying Clang installation changes, namely > # Clang most probably doesn't maintain binary compatibility, so rebuild when clang changes. > $(CLANGOUTDIR)/clang-timestamp: $(CLANGDIR)/bin/clang$(CLANG_EXE_EXT) > $(QUIET)touch $@ in compilerplugins/Makefile-clang.mk, but that doesn't work reliably either, as it depends on the newly installed clang executable being newer than our clang-timestamp file, which will be the case for self-built Clang installations, but not necessarily when updating e.g. a distro-provided Clang installation.) Change-Id: Ie576f14356b3f0e55444375095c86aa851404bf3 Reviewed-on: https://gerrit.libreoffice.org/64623 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-05Jakarta Ant is actually called Apache AntGabor Kelemen1-3/+3
According to https://archive.apache.org/dist/ant/source/ it was renamed in version 1.5.2 (2003!) and we require 1.6.0 anyways Change-Id: I8adce0f67b9599249a3fb653779dad94539abff3 Reviewed-on: https://gerrit.libreoffice.org/64573 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2018-12-04Bump (Linux) Clang baseline to 5.0.2Stephan Bergmann1-26/+41
...as discussed at <https://lists.freedesktop.org/archives/libreoffice/2018-November/081435.html> "minutes of ESC call ...". This no longer sets CLANGVER, CLANG_VERSION, and CLANG_FULL_VERSION when using Apple Clang (on macOS), which uses different version numbers from upstream anyway. But those variables are only used in the context of compiler plugins, which do not work with Apple Clang anyway (which lacks necessary include files). (Also, move "AC_SUBST(COM_IS_CLANG)" up to where it belongs.) Change-Id: Iee37c42ecacf52fa5a07e35241bcd404025e1cdf Reviewed-on: https://gerrit.libreoffice.org/63899 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-11-29Rename Mac OS X to official name macOS in comments and documentationBartosz Kosiorek1-19/+19
Change-Id: I651b7f202fa52ff5f5357a11aa72c43eb7dc7f95 Reviewed-on: https://gerrit.libreoffice.org/64102 Tested-by: Jenkins Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
2018-11-28On Windows, check for at least Visual Studio 2017 version 15.7Stephan Bergmann1-0/+9
...to further restrict the Windows MSVC baseline to not just VS 2017, but to the latest update (as the various updates bring significant improvements for C++11/ 14/17 support; see the mailing list thread starting at <https://lists.freedesktop.org/archives/libreoffice/2018-July/080588.html> "Compiler baselines (was: [Libreoffice-qa] minutes of ESC call ...)"). Change-Id: If6a1b62da1691ae8ae19edb4ed7b35e4b6e46501 Reviewed-on: https://gerrit.libreoffice.org/59209 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-11-28Require at least gperf 3.1, which no longer emits "register"Stephan Bergmann1-17/+7
...as discussed at <https://lists.freedesktop.org/archives/libreoffice/2018-November/081435.html> "minutes of ESC call ..." Change-Id: I47b6d4a7b8370262ca942b4385e2c0e6f0adc613 Reviewed-on: https://gerrit.libreoffice.org/63953 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-11-28Require at least flex 2.6.0, which no longer emits "register"Stephan Bergmann1-2/+2
...according to <https://github.com/westes/flex/blob/ 83d5d1695a2ab1d69ea4d8e7df27146c644876fc/NEWS>. Its use is no longer allowed in C++17, so will start to cause build failures once we restrict builds to at least C++17. (The situation with gperf is similar, but instead of checking for a minimal known-good version that no longer emits "register", we instead check for it indirectly in configure.ac, by creating gperf-produced conftest.inc and including that in the program used to test which -std= value to use. We could have done something similar for flex, but creating suitable flex output for inclusion might be more work than it was for the simple gperf case.) Change-Id: I662c6795ea5fde1420d9712c0ec910c0cadbc350 Reviewed-on: https://gerrit.libreoffice.org/63713 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-11-27Remove --enable-c++17 optionStephan Bergmann1-10/+1
...reverting 0f3b0ec973f06a98c75ef8acfa720a9973e4d2b5 "Avoid C++17 mode for Coverity Scan". As far as I understand, <https://lists.freedesktop.org/archives/libreoffice/2018-November/081454.html> "New Defects reported by Coverity Scan for LibreOffice" has been run against dd0e6849297c18aabe4fc29c0340a2ed1e474eaf "Temporarily drop --disable-c++17 from Coverity builds" but doesn't let issues like the one discussed at <https://lists.freedesktop.org/archives/libreoffice/2017-November/078966.html> "Re: New Defects reported by Coverity Scan for LibreOffice" reappear. So disabling C++17 for Coverity Scan builds appears to no longer be necessary. Change-Id: I22bfd9ad61da00e942a87aa5e1e0d1fab0004d49 Reviewed-on: https://gerrit.libreoffice.org/64121 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Jenkins
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-30 12:30:23 +0000