summaryrefslogtreecommitdiff
path: root/config_host.mk.in
AgeCommit message (Collapse)AuthorFilesLines
2020-06-29Initial WIP steps for building for macOS on Apple SiliconTor Lillqvist1-1/+1
Don't use $host_os="darwin" for both macOS and iOS depending on $host_cpu. Soon macOS will run on either x86_64 or arm64. Instead, use "darwin" (or "macos") for macOS and "ios" for iOS. Some other early changes for arm64-apple-macos, too. Change-Id: Id89987d854ceba2cd87c6222db2081ccdec0c73e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96976 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-06-11Drop configurability of libnumbertext useTor Lillqvist1-1/+0
It was fairly pointless to be able to --disable-libnumbertext. Besides, disabling it broke the ordinal page (etc) numbering feature: "1st", "2nd", "3rd", etc showed up as "Ordinal-number 1", "Ordinal-number 2", "Ordinal-number 3" etc. Change-Id: I645169054a8fdc8dac89cd48b6c369fd61749467 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96119 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-05-26use -Xclang -debug-info-kind=constructor if availableLuboš Luňák1-0/+1
The option, available since Clang10, emits debuginfo for classes with explicit ctors only together with the ctor, which avoids redundant debuginfo for such classes, noticeably saving both build time and disk space. https://reviews.llvm.org/D72427 I've been using this for quite some time, without problems. Change-Id: I24e5339f983cb8d8990185436dd63e00f0d3ce60 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94756 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-05-17external: bundle box2dSarper Akdemir1-0/+3
Bundled box2d with the build system of LO as a static library. If --with-system-box2d was specified checks for instance box2d in the system, defines SYSTEM_BOX2D and uses the library from the system. Change-Id: Ifb05912f2acaff273b25abebafc5af1cac3afec4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94103 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-05-06always build Skia optimized, unless --enable-skia=debugLuboš Luňák1-0/+1
In raster mode the performance may make quite a difference, this is the drawing library (that's now the Windows default) and LO developers mostly do not need to debug Skia itself. Change-Id: I42f0407d37a2294b062a41d94566e8a4f5f4354b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93557 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-04-21CLANG_C -> CLANG_CCLuboš Luňák1-1/+1
Change-Id: I50ed05116df3f295af6406f0ee45610d9e1e031e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92619 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-04-21better handling of SSEx,AVX intrinsics for ClangLuboš Luňák1-0/+8
Clang-cl interprets MSVC's -arch option a bit differently (for MSVC -arch:SSE2 seems to mean SSE2+, but SSE2-only for Clang). So use Clang's -mxxx options when using clang-cl as CC/CXX. Also check intrinsics once again if using CLANG_CC/CXX to compile Skia. Change-Id: I64cd368ef4e5f4fcf1dbe877a1129f418d273a47 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92618 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-04-20prefer building Skia with Clang if possible (tdf#131697)Luboš Luňák1-0/+2
I.e. try to find and use Clang even if the default compiler is something else. Skia is optimized to be built with Clang(-cl) and in CPU-based raster mode some operations are several times slower if built with something else (e.g. fmax/fmin do not get optimized to inline assembly). It is enough to select Clang to be installed in the MSVS installer. At this point it unclear how to handle release binaries, if it should work this way and enforced, or maybe Clang could be used for building everything, or maybe some other way. Change-Id: I6b95a0f2d5cbf176942d9e01136990b14be6dba8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92415 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-04-17HAVE_GCC_BUILTIN_FFS is unusedStephan Bergmann1-1/+0
...ever since it was introduced in 334a9f16cd1d1f9694f885c759903a41aa3d4833 "tdf#113211: fix calculations with big integers". (Only the AC_DEFINE'd #define in config_host/config_global.h.in is used in sal/rtl/math.cxx.) Change-Id: I4b84534b022b96fee725988906c047736e7a579b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92411 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-03-27revert the gyp-based nss build changesLuboš Luňák1-1/+0
https://lists.freedesktop.org/archives/libreoffice/2020-March/084769.html etc. This reverts commit c76fdcf1cfa1242e66b50ebe80d6eac1baae37a9. This reverts commit 10f52ab4d27263439d59f55f40e88ad2fde0cf71. This reverts commit eac806e8dcd9ee6439ac8695978ff6b62cc6b8d2. This reverts commit d591a682e46ff352f06a61c024ef661dd17f4ea4. This reverts commit 12235d3390a7fc5146bf65f9d6166034b8a048ee. This reverts commit 23245f723fb29262b8543d6447d1b0bb69cb50fb. This reverts commit 91658b402b66b67c785687d5b3a76e3183fe76bf. This reverts commit 5feadfad0cc3be2680213d2e5f6f786b2f4cc74f. This reverts commit fecca49c309fc723c524f12fa671114b316a5562. This reverts commit c6a9454e744289cf2004b42b3c90854b2db8382b. This reverts commit a1a62a70411cb6041b5930ead08280d5e1e7b5f9. This reverts commit 8512f4ca090c85477a6670438aeefe7fdfcf8a98. This reverts commit 532ffb7a297d55b495141ce33692df5d9917b54f. Change-Id: Iaa48d692bea2ca2468cdd5f8ad26ad91c0c31dde Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91199 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-03-23actually export $NINJA from configureLuboš Luňák1-0/+1
I based the check on the gmake check, but that one doesn't need the export, as gmake is what needs to be called for the build to start. But ninja is currently only used during building NSS. Also do not use Windows path for ninja on Windows, as NSS actually invokes it from a shell script. Change-Id: I0d8a86ee3688f27a376d547cd946bb4c59a547a2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90922 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-03-09Add --disable-compiler-plugins-analyzer-pch for Jenkins/linux_clang_dbgutil_64Stephan Bergmann1-0/+1
<https://ci.libreoffice.org/job/gerrit_linux_clang_dbgutil/54883/> had been a case I noticed of a "Gerrit Linux clang/dbgutil" build failing due to stale PCH information: [...] > [build GEN] compilerplugins/clang/sharedvisitor/makeshared.plugininfo > fatal error: file '/usr/include/asm-generic/errno.h' has been modified since the precompiled header '/home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/compilerplugins/clang/sharedvisitor/clang.pch' was built > note: please rebuild precompiled header '/home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/compilerplugins/clang/sharedvisitor/clang.pch' [...] and this issue had apparently caused all those Gerrit Jenkins builds to fail for at least a day. For unmaintained builds like those, I think it is better to have a more robust setup, where stale PCH information cannot break the build. Also, as those builds do not make compilerplugins.clean and rather share it across builds, there should not be much of a performance impact when disabling PCH in the analyzer. (It turns out that compilerplugins/clang/sharedvisitor/analyzer.cxx would always have enabled PCH, as compilerplugins/Makefile-clang.mk always passes in some definition of LO_CLANG_USE_ANALYZER_PCH. Fixed that now.) Change-Id: I7b8b24c1049c501634bd59c5fb482bec72427cf6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90211 Reviewed-by: Luboš Luňák <l.lunak@collabora.com> Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
2020-02-20macOS Xcode ld is known to always support -platform_version nowStephan Bergmann1-1/+0
...after 358146bbbd1b9775c12770fb5e497b6ec5adfc51 "Bump macOS build baseline to Xcode 11.3 and macOS 10.14.4". This effectively reverts b7fd89100d8653dc73955780358fe31d38b68ebf "tdf#122218: Baseline Xcode 9.3 ld presumably doesn't support -platform_version". Change-Id: Ib79563babe3cc948556d5369b0f6b6a8d208cab2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89160 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-02-19add --enable-optimized=debugLuboš Luňák1-0/+1
This will use -Og with GCC/Clang instead of -O0, which should make unittests run faster without (hopefully) breaking anything related to debugging. This is primarily meant to Jenkins builds, where debug info is rarely needed (backtraces for unittest crashes AFAICT). This can be also used to make LO itself run faster when developing, but I personally do not find it worth it (with Clang and full PCH this makes starmath build take about 70% longer, although presumably for non-PCH builds the relative increase will be smaller). Change-Id: I198d0759ebca94c90be662e02e0f1281a24d1d70 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88917 Reviewed-by: Michael Stahl <michael.stahl@cib.de> Reviewed-by: Luboš Luňák <l.lunak@collabora.com> Tested-by: Jenkins
2020-02-16MAC_OS_X_VERSION_MIN_REQUIRED_DOTS is the same as MACOSX_DEPLOYMENT_TARGETStephan Bergmann1-1/+0
Change-Id: I3a725e4681c11f503dae57436b05b5a80ff2979c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88764 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-02-14Prevent -Werror,-Wunknown-warning-option when building compilerpluginsStephan Bergmann1-0/+1
...with --enable-werror (seen it fail with a local build against a locally built Clang 5.0.2). (bin/gen-boost-headers faces a similar dilemma with Clang needing to silence -Wunknown-warning-option and GCC failing upon the silencing incantation. There, we were able to hack around that with a preceding #pragma GCC diagnostic ignored "-Wpragmas" Here, the easiest approach appears to be a new COMPILER_PLUGINS_COM_IS_CLANG analoguous to the existing COM_IS_CLANG.) Change-Id: I9036261fdd238c8a020a1d88b4e75fd444f9e030 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88725 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-02-14tdf#122218: Baseline Xcode 9.3 ld presumably doesn't support -platform_versionStephan Bergmann1-0/+1
...according to <https://github.com/llvm/llvm-project/commit/ 25ce33a6e4f3b13732c0f851e68390dc2acb9123> "[driver][darwin] Pass -platform_version flag to the linker instead of the -<platform>_version_min flag": "In Xcode 11, ld added a new flag called -platform_version [...] This patch adopts the new -platform_version flag in Clang, and starts using it by default, unless a linker version < 520 is passed to the driver." So detect new HAVE_MACOS_LD_PLATFORMVERSION and adapt 645fe53be0dc36535dba0ed684e21ca4cda80d70 "tdf#122218: Hack to avoid blurry text with macOS SDK 10.15" accordingly. (This also changes the passed -platform_verion sdk value from 0.0 to 0.0.0, for cosmetic consistency with the default Clang behavior cited above. Also, after f67e5ef9a5c71f3b35b1c67eb72794e44cc15410 "Drop broken filter-out of -bind_at_load for Executable_soffice_bin on macOS" got included in the meantime, the surrounding ifeq in desktop/Executable_soffice_bin.mk can be combined now.) Change-Id: Ie1ddf2d618e2f1232c6b4e17ce17665851f3bd38 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88717 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-01-18use -Wl,-dead_strip on Mac, its linker doesn't know -Wl,--gc-sectionsLuboš Luňák1-0/+1
Change-Id: Ic69d0030a46fe4753cc75da58bb2c15cf009b135 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87023 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-01-18support Clang's -fmodules-codegen/debuginfo options for PCH buildingLuboš Luňák1-0/+2
These (starting with my patches for Clang-to-be-10) allowing emitting debuginfo and functions into a dedicated object file, so that all the normal compilations using the PCH can skip those, thus saving the time. The debuginfo option seems to always be worth it. The codegen option is more tricky, it doesn't seem to be worth it for optimized builds (optimizing all the functions in that one object file costs too much). This requires also using --Wl,--gc-sections . The reason is that the object file contains all template instances instantiated from the PCH, so that they can be shared, but the template instance may come from another library or use a private symbol from that library. For example the std::unique_ptr<ScInterpreterContext> in ScInterpreterContextPool in the header refers to ScInterpreterContext dtor. But even though both these classes are private, the header gets used also by scfilt, because there it is included by document.hxx because of a private ScDocument data member. So even though nothing in scfilt uses ScInterpreterContext, the PCH object file will refer to it. Fortunately that template instance itself is not used by scfilt, so --gc-sections will remove it. Change-Id: I2a06ebcc4dd4175424b3a72ab3ebcaf2ac3ee295 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87011 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-01-18add support for Clang's -building-pch-with-objLuboš Luňák1-0/+1
This marks the PCH as having an accompanying object file, and this object file needs to be also built, but this allows the compiler to skip generating stuff that'd be shared by all the objects using the PCH. Currently it doesn't make much of a difference, few symbols if any, but template instantiations could be shared this way, as soon as Clang gets the necessary support (my WIP patch). Change-Id: Ib1b86338d85a47b48979558435253dc2672a0da8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87009 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-12-12Enable -Wdeprecated-copy-dtor where availableStephan Bergmann1-0/+1
We already get -Wdeprecated-copy (warning about implicitly defined copy functions that will in the future be deleted because other user-provided copy functions exist) automatically through -Wextra, where available. -Wdeprecated-copy-dtor (warning about implicitly defined copy functions that will in the future be deleted because of a user-provided dtor) is split off into its own warning excluded from -Wextra for somewhat unclear reasons, see the discussion at <https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=88136> "-Wdeprecated-copy is draconian and shouldn't be in -Wall". But -Wdeprecated-copy-dtor has been useful in finding issues (esp. the Clang 10 trunk version, which, unlike the GCC 9 version, also finds copy functions that are implicitly defined because they are used from template instantiations), see 3e59716375a240576fd6d8759b32b4319506ed70 "Prevent BroadcastRecalcOnRefMoveHandler copies" and 4f98cd0f9ce9c2a331a5d34b3ef9d18f9bb6b235 "ScShapeChild has broken copy functions". We need to disable -Wdeprecated-copy-dtor in files included from external/boost, and in two compilerplugin/clang/test/ files. Change-Id: I74b159c3a046e23661473ddbfe53c92c4136a9db Reviewed-on: https://gerrit.libreoffice.org/85073 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-06Honor BISON passed into configureStephan Bergmann1-0/+1
...and require new-enough Bison for --enable-compiler-plugins to not generate bogus loplugin:external warnings in Bison boilerplate code. (As happend for me on macOS where /usr/bin/bison is version 2.3. Not sure which versions exactly are too old, but at least 3.4.1 is known good. If other versions newer than 2.3 turn out to be problematic too, the configure.ac check will need to be adapted.) No idea why there need to be three places across solenv/gbuild/ that set gb_YACC (to the same bison in each case), but leave that to be cleaned up later. Change-Id: I01d8219726f8df7895631b817866207327367759 Reviewed-on: https://gerrit.libreoffice.org/84650 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-03split instrinsics CXXFLAGS per each instruction setLuboš Luňák1-1/+8
The common usage pattern should be having one source file per each instruction set and then one source file compiled with neutral flags that dispatches to the relevant code based on runtime checks. Which means that there can't be any one "correct" flag, otherwise all files would get compiled e.g. with SSE4.2 but then CPUs capable only of SSE2 would crash running that code. Change-Id: I362bf66f672dae4588a48effe3bcd30c34ea75b3 Reviewed-on: https://gerrit.libreoffice.org/84227 Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-11-27android: Introduce --enable-android-lok configure switch to fix RGB vs. BGR.Jan Holesovsky1-0/+1
This indicates that the build targets the Online-based Android app, for which we need to avoid various tweaks that are needed for the 'old' Android app present in the android/ subdir of core.git. In particular, the switch used in this patch fixes a RGBA vs. BGRA confusion that caused yellow <-> cyan switch in the Online-based Android app. Change-Id: I5f394868f51ce87013677834cfafb967b9bb333e Reviewed-on: https://gerrit.libreoffice.org/83342 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Jan Holesovsky <kendy@collabora.com> (cherry picked from commit 49002a143a4534df5f6139e07fefd06174621c59) Reviewed-on: https://gerrit.libreoffice.org/83718 Tested-by: Jenkins
2019-11-27initial build of the Skia libraryLuboš Luňák1-0/+1
Not quite complete yet, missing e.g. Vulkan sources, and the setup is not completely correct either. Change-Id: I2283bf12f0d226ff8a34554deae5a7bd69045971
2019-10-12aarch64 callVirtualFunction needs to be compiled w/o -fstack-clash-protectionStephan Bergmann1-0/+1
At least when doing an aarch64 Flatpak build against org.freedesktop.Sdk//19.08, which uses GCC 9.2.0 and passes in `CXXFLAGS=-O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -fasynchronous-unwind-tables -fstack-clash-protection`, callVirtualMethod (in bridges/source/cpp_uno/gcc3_linux_aarch64/callvirtualfunction.cxx) would decrement the stack pointer another 16 bytes after the stackargs = alloca(...); and before the asm block, so in the called virtual function, arguments read from the stack would read garbage (and CustomTarget_testtools/uno_test would fail with SIGSEGV at > #0 0x0000ffffb733eb48 in rtl::OUString::operator= (this=0xaaaaf9c1ac30, str=...) at /run/build/libreoffice/include/rtl/ustring.hxx:453 > #1 0x0000ffffb733a7bc in bridge_object::assign (rData=..., bBool=true, cChar=64 u'@', nByte=17 '\021', nShort=4660, nUShort=65244, nLong=305419896, nULong=4275878552, nHyper=0, nUHyper=187651311381888, fFloat=17.0814991, fDouble=3.1415926358999999, eEnum=-1698898192, rStr=..., xTest=..., rAny=...) at /run/build/libreoffice/testtools/source/bridgetest/cppobj.cxx:99 > #2 0x0000ffffb733a87c in bridge_object::assign (rData=..., bBool=true, cChar=64 u'@', nByte=17 '\021', nShort=4660, nUShort=65244, nLong=305419896, nULong=4275878552, nHyper=0, nUHyper=187651311381888, fFloat=17.0814991, fDouble=3.1415926358999999, eEnum=-1698898192, rStr=..., xTest=..., rAny=..., rSequence=...) at /run/build/libreoffice/testtools/source/bridgetest/cppobj.cxx:115 > #3 0x0000ffffb733ade4 in bridge_object::Test_Impl::setValues (this=0xaaaaf9c1abb0, bBool=1 '\001', cChar=64 u'@', nByte=17 '\021', nShort=4660, nUShort=65244, nLong=305419896, nULong=4275878552, nHyper=0, nUHyper=187651311381888, fFloat=17.0814991, fDouble=3.1415926358999999, eEnum=-1698898192, rStr=..., xTest=..., rAny=..., rSequence=..., rStruct=...) at /run/build/libreoffice/testtools/source/bridgetest/cppobj.cxx:548 > #4 0x0000ffffb740bff4 in callVirtualFunction (function=281473755360772, gpr=0xffffd1ab1f28, fpr=0xffffd1ab1f68, stack=0xffffd1ab1d40, sp=8, ret=0xffffd1ab22c0) at /run/build/libreoffice/bridges/source/cpp_uno/gcc3_linux_aarch64/callvirtualfunction.cxx:63 > #5 0x0000ffffb740ca70 in (anonymous namespace)::call (proxy=0xaaaaf9c291c0, slot=..., returnType=0xaaaaf9c00770, count=17, parameters=0xaaaaf9c3a210, returnValue=0xffffd1ab22c0, arguments=0xffffd1ab2230, exception=0xffffd1ab2370) at /run/build/libreoffice/bridges/source/cpp_uno/gcc3_linux_aarch64/uno2cpp.cxx:178 > #6 0x0000ffffb740d4c4 in bridges::cpp_uno::shared::unoInterfaceProxyDispatch (pUnoI=0xaaaaf9c291c0, pMemberDescr=0xaaaaf9c55950, pReturn=0xffffd1ab22c0, pArgs=0xffffd1ab2230, ppException=0xffffd1ab2370) at /run/build/libreoffice/bridges/source/cpp_uno/gcc3_linux_aarch64/uno2cpp.cxx:361 > #7 0x0000ffffb740720c in (anonymous namespace)::call (proxy=0xaaaaf9c549c0, description=..., returnType=0xaaaaf9c00770, count=17, parameters=0xaaaaf9c3a210, gpr=0xffffd1ab2510, fpr=0xffffd1ab2550, stack=0xffffd1ab2590, indirectRet=0xffffb7d24790) at /run/build/libreoffice/bridges/source/cpp_uno/gcc3_linux_aarch64/cpp2uno.cxx:120 > #8 0x0000ffffb74079a0 in (anonymous namespace)::vtableCall (functionIndex=40, vtableOffset=0, gpr=0xffffd1ab2510, fpr=0xffffd1ab2550, stack=0xffffd1ab2590, indirectRet=0xffffb7d24790) at /run/build/libreoffice/bridges/source/cpp_uno/gcc3_linux_aarch64/cpp2uno.cxx:291 > #9 0x0000ffffb7407b00 in (anonymous namespace)::vtableSlotCall (gpr0=187651311618536, gpr1=1, gpr2=64, gpr3=17, gpr4=4660, gpr5=65244, gpr6=305419896, gpr7=4275878552, fpr0=5.4321266044931319e-315, fpr1=3.1415926358999999, fpr2=0, fpr3=4.0039072046065485, fpr4=0, fpr5=4.003911019303815, fpr6=8.9589789687541617e+102, fpr7=-4.4588500238274385e-308) at /run/build/libreoffice/bridges/source/cpp_uno/gcc3_linux_aarch64/cpp2uno.cxx:348 > #10 0x0000ffffb739e60c in bridge_test::performTest (xContext=..., xLBT=..., noCurrentContext=false) at /run/build/libreoffice/testtools/source/bridgetest/bridgetest.cxx:378 > #11 0x0000ffffb73a3d58 in bridge_test::TestBridgeImpl::run (this=0xaaaaf9c18550, rArgs=...) at /run/build/libreoffice/testtools/source/bridgetest/bridgetest.cxx:1162 > #12 0x0000aaaad292a3ec in sal_main () at /run/build/libreoffice/cpputools/source/unoexe/unoexe.cxx:509 > #13 0x0000aaaad29297a0 in main (argc=8, argv=0xffffd1ab31b8) at /run/build/libreoffice/cpputools/source/unoexe/unoexe.cxx:349 .) By experiment, I found the problematic thing to be -fstack-clash-protection, which can apparently be cancelled with a subsequent -fno-stack-clash-protection at least on that GCC 9.2.0. (And -f[no-]stack-clash-protection appears to only be available since GCC 8, and not at all for Clang, so check for it with HAVE_GCC_STACK_CLASH_PROTECTION.) Change-Id: If667fdf704b1ba20a04593b38d2d1f079280df41 Reviewed-on: https://gerrit.libreoffice.org/80701 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-12-fstack-protector-strong is long since availableStephan Bergmann1-1/+0
...on our baselines, since <https://gcc.gnu.org/git/ ?p=gcc.git;a=commitdiff;h=b156ec373ccf27f4fcce7972de5e043d35acea43> (GCC 4.9?) and <https://github.com/llvm/llvm-project/commit/ e0fc1a80cba8b91e3943f3287e7dcf68c6bb9b7f> "[stackprotector] Add command line option -fstack-protector-strong" (Clang 3.5?) Change-Id: I48237b2304a1ee273cc66f0bb458e890a5a2f21a Reviewed-on: https://gerrit.libreoffice.org/80700 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-07try to autodetect flags needed to build Clang pluginsLuboš Luňák1-0/+3
Instead of having a lot of it hardcoded, which brings problems like: - Clang-to-be-10 has switched to -std=c++14, so our hardcoded c++11 makes the build fail - I cannot compile with my openSUSE-shipped clang, because it ships only libclang-cpp and not the other libClangSomething libs The possibility to explicitly set the necessary variables is still there. Change-Id: I58d401d4584fa064f1c1351a8a06ff4e29643063 Reviewed-on: https://gerrit.libreoffice.org/80300 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-10-02tdf#127711 - A runtime-switch for the MiniCrashDumpJuergen Funk1-0/+1
- in soffice.ini (sofficerc) the entry "CrashDumpEnable" default is "true" - when false then the Dump.ini and the dump-file are not written - when the switch --disable-crashdump is set, then the switch "CrashDumpEnable" set to "false" - when the entry "CrashDumpEnable" is missing, in this case is the default true, too - the checkbox under Options-General "Send crash reports to ..." is deactive and shows off (only view, not change the config) - when set the environment variable "CRASH_DUMP_ENABLE" to any char then the switch "CrashDumpEnable=false" are overrules with true and the Dump.ini and dump-file are write Change-Id: I34e7795640eb95d111e18b0ad46ec67b2c126b19 Reviewed-on: https://gerrit.libreoffice.org/79273 Tested-by: Jenkins Reviewed-by: Juergen Funk (CIB) <juergen.funk_ml@cib.de>
2019-10-01redmine#2555 replace Help online Google searchOlivier Hallot1-0/+1
This is the core/ part of the patch. Add xapian-omega search to online Help. The patch replaces Google custom search with xapian-omega search. A new build key is introduced. --with-omindex=server : Localizes and adds the xapian result page, adds the xapian form to each Help page. --with-omindex=noxap : do not localize the result template and do not add a form in the Help page. --with-omindex will force Online Help build. Default is noxap NOTES: - searches returns resuls only on localized Help pages, avoiding same resulis in many languages. -xapian-omega databases must be built in server TODO: - Tweak the xapian-omega result page CSS and markup. Change-Id: I5e3fe4191a3b054e3b6403f7cb5640953d92ba42 Reviewed-on: https://gerrit.libreoffice.org/79368 Tested-by: Jenkins Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
2019-09-30drop gtk2 supportCaolán McNamara1-7/+0
Change-Id: Ie838cabfecfef7e3225c1555536d5c9cf3b43f15 Reviewed-on: https://gerrit.libreoffice.org/77405 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-09-20Remove legacy NEED_CLANG_LINUX_UBSAN_RTTI_VISIBILITY supportStephan Bergmann1-1/+0
...for ASan/UBSan builds using Clang older than current trunk twoards Clang 9, as announced at <https://lists.freedesktop.org/archives/libreoffice/2019-May/082654.html> "Re: [Libreoffice-commits] core.git: The -fvisibility-ms-compat hack is no longer needed for UBSan on Linux...". (And drop the no longer needed solenv/sanitizers/asan-suppressions, which people might still reference from their ASAN_OPTIONS.) Change-Id: Iedc0c5955366d2cbe7dc847990e2b1576750e85b Reviewed-on: https://gerrit.libreoffice.org/72493 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-09-02add -latomic configure check...Rene Engelhard1-0/+1
...in preparation for <https://gerrit.libreoffice.org/#/c/78380/> "Add -latomic to the end of Linux C++ linker command lines" (copied from https://github.com/zelcash/zelcash/blob/master/build-aux/m4/l_atomic.m4) Change-Id: I8879a72d730cc08a72c2d8b132ff9f5d2efe7b9f Reviewed-on: https://gerrit.libreoffice.org/78336 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-07-21tdf#125922 rename kde5 to kf5 + plasma5Jan-Marek Glogowski1-1/+1
Just as the gtk3 plugin isn't named GNOME, rename kde5 to kf5, as it is based on the KDE frameworks 5 libraries. This also includes: * a convenience alias to load the kf5 VCL plugin in case someone requests the kde5 plugin. * keep convenience kde5 configure switch, but warn about it * rename detected desktop from kde5 to plasma5 Change-Id: I6764a05b81a5edbf284484c234fee2649aacf735 Reviewed-on: https://gerrit.libreoffice.org/75313 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-07-19missing LDAPCaolán McNamara1-0/+1
since... Make LDAP support optional commit 6776c53b7ce2e431d8636f4e5a755f50f787ec8f Date: Tue Jan 8 04:53:51 2019 -0500 Change-Id: I4268169809b0dc68b347b28523500453394937de Reviewed-on: https://gerrit.libreoffice.org/75865 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-07-09CPU intrinsics detection (SSE, AVX)Tomaž Vajngerl1-0/+1
Adds CPU intrinsics detection in configure pass for compile time detection and "cpuid" runtime detection of which CPU instruction sets are available on the user device. Change-Id: I0ee4d0b22a7c51f72796d43e7383a31d03b437ad Reviewed-on: https://gerrit.libreoffice.org/75175 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2019-07-03Drop unused MOC4 exportJan-Marek Glogowski1-1/+0
Was missed when the kde4 VCL plugin got removed. Change-Id: Ia6e7fb87577572d450c7851b5559041dea68d19e Reviewed-on: https://gerrit.libreoffice.org/75023 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-07-02Fix typo in codeAndrea Gelmini1-1/+1
Change-Id: I5b3f9df553da1d4ad76d1b914b4d39601ee0ae55 Reviewed-on: https://gerrit.libreoffice.org/74999 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Michael Stahl <Michael.Stahl@cib.de> Tested-by: Jenkins
2019-07-02bundle external: qrcodegenShubham Goyal1-0/+3
The bundle helps to generate QR code in LO. Change-Id: Iaa9225a72d15806c929d30951cefd3f3fee8960e Reviewed-on: https://gerrit.libreoffice.org/73302 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2019-06-13Don't link avmediagst with gtk3 and qt5Jan-Marek Glogowski1-3/+3
While the VCL plugins are dynamically loaded and therefore just load their depending toolkit libraries, the GStreamer avmedia backend now links against Qt and GTK+. The GStreamer API itself is toolkit agnostic and the toolkit setup just uses a single GStreamer symbol to create the specific video sink. So the toolkit binding can simply be moved into the VCL plugin. At the point of the GStreamer toolkit setup call the GStreamer library is loaded by avmediagst, so the dlsym lookup should never fail. I also dropped the special GtkWidget handling. Using g_object_get will increase the refcount of the widget. A g_object_unref after adding it to the container seems to destroy it correctly. Change-Id: I693947e441bceb4b09bc38920e308e39142d0a35 Reviewed-on: https://gerrit.libreoffice.org/73849 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-06-07Drop support for gstreamer-0.10Michael Weghorn1-3/+0
Drop all GStreamer 0.10 support according to ESC decision of 2019-06-06. GStreamer 0.10 is obsolete and no longer needed, superseded by GStreamer 1.0 which is available in baseline (RHEL 7 or CentOS 7) and all relevant distros. Change-Id: Ic317eba04d2c17e141acc983f37fbfa4301c9f3f Reviewed-on: https://gerrit.libreoffice.org/73619 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2019-05-09if ccache is enabled, by default also enable CCACHE_DEPENDLuboš Luňák1-0/+1
This avoids the preprocessing step normally done by ccache (see ccache docs), which speeds up the build. This way there may be incorrect ccache hits if a system header (found using -isystem) changes, but that should be rare and such headers generally should be backwards compatible, so the chance of an actual breakage should be very low. The patch also adds --enable-ccache=nodepend to allow enabling ccache without the depend mode. https://lists.freedesktop.org/archives/libreoffice/2019-May/082684.html Change-Id: Id69ca43988a016a917beb75927b39d8bde719aa7 Reviewed-on: https://gerrit.libreoffice.org/71629 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-05-07Drop LINK_X64_BINARY: any MSVC linker is suitable for any target platformMike Kaganski1-1/+0
Change-Id: I8b080ad44f10e52fa5a726bd7cdf7dd8ff7e2dd4 Reviewed-on: https://gerrit.libreoffice.org/71913 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-05-03The -fvisibility-ms-compat hack is no longer needed for UBSan on Linux...Stephan Bergmann1-0/+1
...with latest Clang trunk towards Clang 9. All the no-longer necessary hacks are made conditional on new NEED_CLANG_LINUX_UBSAN_RTTI_VISIBILITY, which is still set for UBSan builds with older Clang on Linux (but which should eventually be purged). Various classes needed additional SAL_DLLPUBLIC_RTTI annotations, as building with UBSan instrumentation can generate references to RTTI symbols from additional places like outside a dynamic library that used to hide those symbols by default (but used to not hide them for old UBSan builds thanks to the -fvisibility-ms-compat hack). The odr-violation suppressions in solenv/sanitizers/asan-suppressions (which is not referenced from anywhere in the code base, but meant to be included in an ASan/UBSan build's ASAN_OPTIONS env var) are also no longer needed when NEED_CLANG_LINUX_UBSAN_RTTI_VISIBILITY is false. Change-Id: I24ec3e388b0cbab50dbe2bf008d9569bff7bf25a Reviewed-on: https://gerrit.libreoffice.org/70829 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-04-11merge --enable-selective-debuginfo into --enable-symbolsLuboš Luňák1-2/+1
This got broken again due to confusion about the interaction between the various debug/symbol/whatever variables, so let's try to clean it up once more. So gb_SYMBOLS or any other global flag is no more. For checking whether a build target should get symbols, use gb_LinkTarget__symbols_enabled, which is internally controlled by gb_ENABLE_SYMBOLS_FOR (and flags from configure, command line or wherever affect that). This commit breaks the debug/nodebug split for PCH files, but fixing that is a relatively separate and complex change, so it'll be done in another commit. Change-Id: I6060dd38684445bb761e664344fb530386481332 Reviewed-on: https://gerrit.libreoffice.org/70369 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-03-22Allow to pass additional options into generator's clang::toolingStephan Bergmann1-0/+1
In my macOS build, that clang::tooling::runToolOnCodeWithArgs invocation failed to find headers like cassert and assert.h, which works now with COMPILER_PLUGINS_TOOLING_ARGS=-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -isystem /Users/stephan/Software/llvm/inst/include/c++/v1 added to my autogen.input (I build against my Clang trunk libc++ whose headers are at /Users/stephan/Software/llvm/inst/include/c++/v1). Change-Id: Idbffa39c9fd4a88743fd498b8f7b6c9c56d7630d Reviewed-on: https://gerrit.libreoffice.org/69538 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-03-07build: support disabling popplerAshod Nakashian1-0/+1
This adds --enable-poppler configure option. Poppler can be enabled/disabled by setting this parameter to yes or no. Change-Id: I42ba2d27de7b5014d28523394310616d20073b71 Reviewed-on: https://gerrit.libreoffice.org/68602 Reviewed-by: Andras Timar <andras.timar@collabora.com> Tested-by: Andras Timar <andras.timar@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/68842 Tested-by: Jenkins
2019-01-24Drop unnecessary gb_DEBUG_CFLAGSStephan Bergmann1-2/+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-1/+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/+1
...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>
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-28 17:31:31 +0000