summaryrefslogtreecommitdiff
path: root/config_host/config_global.h.in
AgeCommit message (Collapse)Author
2018-09-11Use [[fallthrough]] also with MSVCStephan Bergmann
Change-Id: I840de9460c164b86dcbd96b4c0f382e1a1b609a2 Reviewed-on: https://gerrit.libreoffice.org/60330 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-09-11Use [[nodiscard]] in SAL_WARN_UNUSED_RESULT where availableStephan Bergmann
...which required some lax placements of SAL_WARN_UNUSED_RESULT to be fixed. Also, Clang unfortunately is rather picky about the relative order of SAL_WARN_UNUSED_RESULT expanding to [[nodiscard]] and uses of the DLLPUBLIC macros (expanding to __attribute__(...) resp. __declspec(..) for clang-cl). Change-Id: Iae6ca36bef97f1864873aefdb5f05c7f5e045ad3 Reviewed-on: https://gerrit.libreoffice.org/60274 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-08-31GCC only supports inline variables since GCC 7Stephan Bergmann
(see also discussion at <https://gerrit.libreoffice.org/#/c/59204/11> "new loplugin:conststringfield" about its changes to registry/source/regimpl.cxx) Change-Id: Id2743adbfeb4d7c42105a65ba8400d7051da2f03 Reviewed-on: https://gerrit.libreoffice.org/59873 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-08-30Silence bogus -Werror=redundant-move (GCC 9)Stephan Bergmann
Change-Id: Ia078fb8e1e497edfa08e2a61d1659100461fc52e Reviewed-on: https://gerrit.libreoffice.org/59720 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-08-29-Werror=redundant-move (GCC 9), take twoStephan Bergmann
...after 5b62a43349da6fda13fb33e0f1ec477c21daec8f "Revert '-Werror=redundant-move'" to fix the build for GCC 8.1 again. Turns out the std::move can only be dropped if the compiler has a fix for CWG1579. For GCC that's the case starting with GCC 5.1, so the !HAVE_CXX_GWG1579_FIX case can hopefully be removed again soon, see the mail thread starting at <https://lists.freedesktop.org/archives/libreoffice/2018-July/080588.html> "Compiler baselines (was: [Libreoffice-qa] minutes of ESC call ...)"). Change-Id: I3592cad7fb503db921c37e92831a34785a1054a1 Reviewed-on: https://gerrit.libreoffice.org/59741 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-07-04Make brittle SortedAutoCompleteStrings ownership handling more explicitStephan Bergmann
Change-Id: Ieaf2231a84d97528bb1b9a410c4ee0c38966dd27 Reviewed-on: https://gerrit.libreoffice.org/56950 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-11-08Drop HAVE_GCC_ATTRIBUTE_WARN_UNUSED_STLStephan Bergmann
For one, loplugin:unusedvariablecheck does not merely check for unused variables with types from the standard library since fe2164949b38a7f73883dbdcb3271b94e5c81744 "teach unusedvariablecheck plugin about SfxPoolItem subclasses", so disabling loplugin:unusedvariablecheck based on HAVE_GCC_ATTRIBUTE_WARN_UNUSED_STL is wrong. For another, I have seen no standard library implementation that decorates its types with such "warn-if-unused" attributes, and <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0600r0.pdf> "[[nodiscard]] in the Library" (which proposes to add the corresponding C++17 attribute to just a few select functions and no types at all) makes it appear unlikely that will happen. Change-Id: I0a7759e1caf3e3137057c9689080948a4d6747e0
2017-10-19tdf#113211: fix calculations with big integersMike Kaganski
... and munbers with few fractional bits Change-Id: I86c3e8021e803fed498fae768ded9c9e5337c8bd Reviewed-on: https://gerrit.libreoffice.org/43477 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Eike Rathke <erack@redhat.com>
2017-06-16Remove HAVE_CXX11_REF_QUALIFIER, always true nowStephan Bergmann
...after 579497164f6bddfeb14bb6b0f4b9cd3322af1803 "Bump GCC baseline to 4.8.1" Make this a fatal configuration error for now. The check should be removed completely after LO 6.0 branch-off. Change-Id: I70cf65d6b0eb7158008f28449794c66c1b775916 Reviewed-on: https://gerrit.libreoffice.org/38869 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-06-01HAVE_THREADSAFE_STATICS sould always be trueStephan Bergmann
...(for LIBO_INTERNAL_ONLY), now that the status of Android has been clarified, see <https://lists.freedesktop.org/archives/libreoffice/2017-June/077827.html> "Re: Some baseline thoughts" Change-Id: Ie9d5444df84c23d48c24b68d9d2ab5322c619858
2017-03-02Remove HAVE_CXX11_UTF16_STRING_LITERAL, always true nowStephan Bergmann
...after 84b36c704d73362d4d86dc9e9c0efa0625958347 "Drop support for MSVC 2013". Make this a fatal configuration error for now. The check should be removed completely after LO 5.4 branch-off. Change-Id: If2f196abb93607dde9ba5c4f04d219679585e633 Reviewed-on: https://gerrit.libreoffice.org/34822 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-03-02Remove HAVE_CXX11_CONSTEXPR, always true nowStephan Bergmann
...after 84b36c704d73362d4d86dc9e9c0efa0625958347 "Drop support for MSVC 2013". Make this a fatal configuration error for now. The check should be removed completely after LO 5.4 branch-off. Change-Id: I990fd8fcb4ec1327282df4efe21640c938d3cf06 Reviewed-on: https://gerrit.libreoffice.org/34821 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2016-12-15Phase out support for HAVE_BROKEN_STATIC_INITIALIZER_LISTStephan Bergmann
...I'm pondering a change that would make that a hard requirement, and from the comment in configure.ac it looks like only old Clang < 3.4 were affected. Change-Id: I8ef64f759fed1a45d88f94d0e8a60839ad10b263 Reviewed-on: https://gerrit.libreoffice.org/32029 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2016-12-12[API CHANGE] Remove salcpprt static libraryStephan Bergmann
...containing replacements for global operator new/delete (that can be linked into executables), but which is no longer used. The mail thread starting at <https://lists.freedesktop.org/archives/libreoffice/2012-March/028690.html> "operator new no longer routes through rtl_AllocMemory in libsalcpprt under gbuild link rules" has the details of how this was used on some platforms (but not on others) before the switch to gbuild, and has been "lost" ever since---but apparently a loss not mourned much over the years. For the SDK, c5f974287fd04bb529de145113133b9e35687702 "INTEGRATION: CWS jsc3: #i62434# copy libsalcpprt.a" added the library (under Linux) and 6db9c5af960f9787e33e4addc56bddbb1695a402 "INTEGRATION: CWS jsc3: #i62434# extend link options for executbales to link libsalcpprt.a, LINUX only" added its use to odk/settings/settings.mk, but fc0ca57f2cd649c6330171445a06b80e2143a0e9 "INTEGRATION: CWS jsc21" removed that use again (for no documented reason). So this is an incompatible change, but unlikely to actually affect any users of the SDK. Change-Id: Ia38b4c439f21fca3f5d9af7d1a34054e992054e9 Reviewed-on: https://gerrit.libreoffice.org/31810 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2016-08-29Support ConstCharArrayDetector also for UTF-16 arraysStephan Bergmann
The long-term benefit will be support of C++11 char16_t string literals (for cases of string literals with non-ASCII content) once we drop any compilers that don't support those yet. The short-term benefit is support for an improved OUStringLiteral1 that accepts any sal_Unicode value, not just ASCII ones (see next commit). Change-Id: I3f8f6697d7eb62b5176b7e812b5a5113c53b83a4 Reviewed-on: https://gerrit.libreoffice.org/28445 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2016-03-31Typo in HAVE_BROKEN_STATIC_INITILIZER_LISTStephan Bergmann
Change-Id: Ia29868d1832b529d438a5a5448b751683c226846
2015-11-09Prevent += called on temporary O[U]String instancesStephan Bergmann
...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
2015-10-12HAVE_CXX11_PERFECT_FORWARDING is required on all supported toolchainsStephan Bergmann
Change-Id: I8f4d7f8ebdfa0fb2c5a8efc676d1f66876b6daa9
2015-10-12HAVE_CXX11_FINAL is required on all supported toolchainsStephan Bergmann
Change-Id: I85ed86fdd8b11863c96b7a6c3ba76d77dbecf192
2015-10-12HAVE_CXX11_OVERRIDE is required on all supported toolchainsStephan Bergmann
Change-Id: Ibc5462642d0a3cd0f96668472ddc0ac0ae407132
2015-10-12HAVE_CXX11_DELETE is required on all supported toolchainsStephan Bergmann
Change-Id: I53c746be98972c7024dc2f340738182e46c24241
2015-09-30Avoid unhelpful -Wunused-variableStephan Bergmann
...at least from "g++ (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4)" with --disable-debug, when a namespace-scope const variable with a "complex" initializer declared in an include file remains unused. Avoid that warning via SAL_CONSTEXPR, which in turn requires large parts of o3tl::is_typed_flags to be SAL_CONSTEXPR, which in turn requires a new HAVE_CXX14_CONSTEXPR to allow assert in constexpr functions, which in turn requires using -std=c++14 instead of -std=c++11 where available, which in turn (a) requires to /not/ use -std=c++14 if it would run into a bug between Clang and libstdc++ discussed at <https://llvm.org/bugs/show_bug.cgi?id=24115> "llvm-nm fails to build with gcc 5.1's libstdc++" (and which hits us in sfx2/source/control/thumbnailview.cxx), and (b) requires a new HAVE_CXX14_SIZED_DEALLOCATION to work around GCC 5.1 -Werror=sized-deallocation (where Clang >= 3.7 only supports C++14 sized deallocation when explictly enabled via -fsized-deallocation, btw). This effectively reverts ff6462e6307e6924dc6c8178043ae9032f4b4152 "avoid unused variable warning:" again. Change-Id: I424e3561452a3e6d8c8a9604d6c737cab49840c4 Reviewed-on: https://gerrit.libreoffice.org/18918 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2015-06-19Fix check for broken standard libraryStephan Bergmann
The compiler's __GNUC__ etc. need not match the libstdc++ version used (esp. when using Clang as compiler), and libstdc++'s __GLIBCXX__ macro doesn't inrease monotonically with version numbers, so resort to a configure check. Change-Id: I06de6b68324169863f6f5c31ae5d855e8b04cd6b
2015-02-10Properly check for Clang with static initializer_list bugStephan Bergmann
Change-Id: I98060f1adae0ba8ec03b2f0d6b0db6d5a1c0385c
2015-02-06Make OUStringLiteral more usefulStephan Bergmann
...don't dare make it non-explicit, yet. Along the way, introduce SAL_CONSTEXPR. Change-Id: Ia3179d0d5e001fd7aa92237c97437e9b74366ee1
2014-10-02remove HAVE_GCC_PRAGMA_DIAGNOSTIC_SCOPE check and macroMichael Stahl
This is supported in GCC 4.6.0 already: https://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Diagnostic-Pragmas.html Change-Id: I2f67e588eea3a323a2e9c81e39e56ab2e715a817
2014-10-02remove HAVE_GCC_PRAGMA_DIAGNOSTIC_MODIFY check and macroMichael Stahl
This has been supported by GCC and clang for a very long time. Change-Id: I410a2b39004c932003f8cbefe935aedb109b1163
2014-09-11(Rudimentary) C++11 support is a hard requirement nowStephan Bergmann
Change-Id: I43ed776d52336b822aa6152f0f2a29e39303bb75
2013-08-05do not base feature checks on gcc versionLuboš Luňák
Clang reports itself to be gcc4.2, so there fail there, instead use configure checks. Change-Id: Idb44a5c875b24a15546a6495de02a1b4af898443
2013-07-23adjust for upstreaming of warn_unused attributeLuboš Luňák
The warn_unused attribute has been upstream to GCC and Clang, so use it if present. Still warn about STL types if those do not use it yet (which is the status as of now). Change-Id: I3c003e44c08d1d141e23bba38cf92e663a5ac353
2013-06-13rename HAVE_CXX0X->HAVE_CXX11 and clean up to #define in a config headerLuboš Luňák
Change-Id: Id13e77fe890301a8510952994a91853568a7aea6
2013-04-08Check for the C++11 "final" specifier and introduce SAL_FINALTor Lillqvist
I think it is useful to use SAL_FINAL mainly as a documentation aid, to make it clear to a code reader when a class is not expected to be derived from, and when a virtual function is not expected to be overridden in a derived class. Possibly there is also some class of bugs that using SAL_FINAL will help find? Change-Id: I45002f020dcb52e8a9f2962ff98780f2b80627af
2013-04-04remove HAVE_SFINAE_ANONYMOUS_BROKENLuboš Luňák
Since we no longer support the old Apple SDK using gcc-4.0.1, we can remove the cruft to work around its problems. Woohoo. Change-Id: Idf275e76449443f1f0314e75dab993f213a77eb7
2013-03-26autoconf can actually handle #define HAVE_FOO 0 as the defaultLuboš Luňák
Change-Id: I6cd70d885a3fe3ab53f7523d1a5da6ae30ee01e3
2013-03-25Introduce HAVE_GCC_PRAGMA_DIAGNOSTIC_{MODIFY,SCOPE}Stephan Bergmann
...replacing hard-coded GCC version checks. Those checks that guard #pragma GCC diagnostic ignored "-Wnon-virtual-dtor" appear relevant only for GCC itself, not Clang (which used to fail the old guards because it typically announces itself with a rather low __GNUC__/__GNUC_MINOR__ version), see 6e67c03dc0225fc66343546b14e902b9d238b1a3 "Enable -Wnon-virtual-dtor for GCC 4.6" Change-Id: I6bfa4d5caa6192e7a203ce829682bf6bb8d61a1b
2013-03-20use #if instead of #ifdef for testing config_xxx.hxx macrosLuboš Luňák
http://lists.freedesktop.org/archives/libreoffice/2013-March/047769.html Change-Id: I81ed4500878ff3193e028410a1f0205e28d17fc3
2013-02-14rhbz#908674: Adapt rtl::Allocator::construct to C++11Stephan Bergmann
...otherwise, at least with some --with-system-boost versions and C++11 compilers, like with Fedora's boost-1.50.0-4.fc18.x86_64 and gcc-c++-4.7.2-8.fc18.x86_64, using this to copy-construct an instance of boost::unordered::detail::ptr_node<std::pair<rtl::OUString,Bootstrap_Impl*>> in the call to p_bootstrap_map->insert(...) in rtl_bootstrap_args_open (sal/rtl/source/bootstrap.cxx) would memcopy the ptr_node and fail to call rtl_uString_acquire, leading to memory corruption later on when rtl_uString_release is called one time too often. It is not entirely clear to me whether this is a shortcoming of the given Boost version, but this patch solves the problem and brings rtl::Allocator::construct in line with the (changed) Allocator requirements of C++11 anyway. The problem potentially lurks with every use of rtl::Allocator, but only showed now begining with LO 4.0 where e5111574fd904b38a3980ca4ea3d21cfcb22dea6 "Revert 'sb140: sb140: #i116981# clean up memory upon exit'" re-introduced code into rtl_bootstrap_args_open that inserts into a boost::unordered_map that uses rtl::Allocator. Change-Id: I3be22f59a8eb49d31458480c27f3ce15803c7fd4
2013-01-31Use separate config_*.h files for BUILD and HOST when cross-compilingTor Lillqvist
We have only been lucky so far that there hasn't been any compilation errors caused by using the HOST platform config_*.h files also for the BUILD platform. But as more and more information found out during configury is stored in config_*.h files, sooner or later it will be a problem. Move config/* to config_host/*. When not cross-compiling, the config_*.h files in config_host expanded from config_*.h.in are all there is. When cross-compiling, the generated config_*.h files for the BUILD platform are put into a config_build folder. Then use config_build when building the cross_toolset and config_host otherwise. Change-Id: I3c28cc83866bffd696b45d00dfb68e00bc2ae538
generated by cgit (git 2.34.1) at 2024-07-15 09:09:22 +0000