summaryrefslogtreecommitdiff
path: root/solenv/gbuild/platform
AgeCommit message (Collapse)Author
32 hoursmake MSVC /analyze a configure optionNoel Grandin
My debug build is slow enough already, no need to make it worse. People who want it, can turn it on explicitly. Change-Id: I8677534d8f0142699baa6b95a249ae5f70c5cc3c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170269 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
11 daysOnly use -Wv:18 in Visual Studio 2019Mike Kaganski
And fix the warnings discovered in Visual Studio 2022: C:/lo/core/cli_ure/source/uno_bridge/cli_proxy.cxx(714): warning C4456: declaration of 'numMethods' hides previous local declaration C:/lo/core/cli_ure/source/uno_bridge/cli_proxy.cxx(681): note: see declaration of 'numMethods' C:/lo/core/cli_ure/source/uno_bridge/cli_proxy.cxx(1032): warning C4457: declaration of 'pUnoI' hides function parameter C:/lo/core/cli_ure/source/uno_bridge/cli_proxy.cxx(918): note: see declaration of 'pUnoI' C:/lo/core/cli_ure/source/uno_bridge/cli_uno.cxx(109): warning C4456: declaration of 'param' hides previous local declaration C:/lo/core/cli_ure/source/uno_bridge/cli_uno.cxx(84): note: see declaration of 'param' C:/lo/core/cli_ure/source/uno_bridge/cli_uno.cxx(256): warning C4456: declaration of 'param' hides previous local declaration C:/lo/core/cli_ure/source/uno_bridge/cli_uno.cxx(240): note: see declaration of 'param' Change-Id: I99abcf17c7c431a403a488c53b65ef34d66d0940 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169782 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
11 daysFix the warning descriptionMike Kaganski
Change-Id: I355e4ab73f58303c3b423ec4230bd55ded95da05 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169785 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-06-19use gb_StaticLibrary_WORKDIR and gb_Library_DLLDIR more consistentlyChristian Lohmaier
same for gb_Executable_BINDIR[_FOR_BUILD] and fold gb_Library_WORKDIR_FOR_BUILD into gb_Library_DLLDIR_FOR_BUILD (the latter also has a workdir variant) Change-Id: If7e4cf9aab46728182c89344546065bc33b452b4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169201 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2024-06-07Modernize wasm debug symbol generationThorsten Behrens
Rolling a few suggested split debug changes from https://developer.chrome.com/blog/faster-wasm-debugging/ into our code. Added emdwp after linker line, to collect .dwo DWARF info into one single file (otherwise Chrome lacks local variable support) Still not working: * -gdwarf-5 does not work yet with neither -O1 nor -Og * -Og results in massive binary sizes, -O1 still required to not blow up browser mem right after load Change-Id: Ibf9ea42882df88d947f9bb3881430f0745c0df54 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168562 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2024-06-07Make Embind-related code also available under --disable-dbgutilStephan Bergmann
...and just keep embindtest.js --enable-dbgutil--only. For convenience when using EMSCRIPTEN_EXTRA_SOFFICE_POST_JS recently introduced in 82640810efd1636e358c047a1a5b3e4e3fc9d28a "New EMSCRIPTEN_EXTRA_SOFFICE_POST_JS configure variable". Change-Id: I03311d89ff14a70f84e03e99ab8e609641ea589b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168552 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Tested-by: Jenkins
2024-06-04Fix typoAndrea Gelmini
Change-Id: I2c8899e5ab779dbd94c5096c72e2fbb09e40d4ad Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168377 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2024-06-03disable MSVC -analyse when run in CI - build time penalty is too muchChristian Lohmaier
times went from 55min to 88min when doing a single build Change-Id: I9304eae9f2326c206bd571e7b8a3ef861206282f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168362 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-05-29Emscripten: Unconditional --enable-wasm-exceptionsStephan Bergmann
(...which will be beneficial, in turn, to implement exception handling in the work-in-progress bridges/source/cpp_uno/gcc3_wasm UNO bridge). As per <https://developer.mozilla.org/en-US/docs/WebAssembly#browser_compatibility>, Wasm exceptions appear to be supported by most if not all relevant engines by now. * Lets see whether the "Note that to really use WASM exceptions everywhere" for external libraries in solenv/gbuild/platform/EMSCRIPTEN_INTEL_GCC.mk does have any practical consequences (but ignoring it for now). * This change depends on the preceding 77129fbb74bcefde4551d494f029169e7c6026e3 "Emscripten: Add hack to prepare for --enable-wasm-exceptions" to work around the issue that was mentioned in static/README.wasm.md. * In unotest/source/embindtest/embindtest.js, getExceptionMessage started to work now, no longer exhibiting the RuntimeError that had been documented there for non-Wasm-based exceptions. Change-Id: Ifa2165b62208cc927844684911ddf21a4a2b624f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168169 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-05-17introduce SAL_RET_MAYBENULLCaolán McNamara
which for debug builds and MSVC uses _Ret_maybenull_ and -analyze to enforce null checking Change-Id: Id7f0ad854be7841819fdbdcd56c862d1a2df86c3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166734 Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> Tested-by: Jenkins
2024-05-07Add gb_Library_add_generated_asmobjectsStephan Bergmann
...to be used by a follow up commit in EMSCRIPTEN's bridges/Library_cpp_uno.mk Change-Id: Iaebc18d40241d9b7918061100b25cca8a8bc4e0e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167291 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-05-07fix Windows incremental buildNoel Grandin
after commit 4c86718e78c6b18c84774e48ca025694364c251a Author: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> Date: Thu Apr 18 12:45:01 2024 +0200 initial support for running autogen.sh inside wsl from git-bash otherwise we end up with mixed cygwin/windows paths in our .d files, which the make executable we use will not like. Change-Id: Ia1325793f47657a23774c216df319ae6afd6d638 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167269 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2024-05-03makefile simplification: replace $(call gb_CustomTarget_get_workdir,foo)Christian Lohmaier
…by a simple/static $(gb_CustomTarget_workdir)/foo The build system has a lot of overly complicated leftovers from when it was introduced and had not only deal with split repositories but also had to coexist with another buildsystem. Along with lots of copy'n'paste along the years the makefiles became hard to grasp for newcomers with all our calls and evals. As a first step to streamline that, the macros from TargetLocations that simply prefix a static path to the argument (and similar of the same kind) are a natural pick before simplifying the rules themselves/getting rid of a bunch of eval statements. Change-Id: Ia06dbbcd5d1994755a2ff05b84f72ccbc4e3cab5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167005 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2024-05-02Prepare to run (select) tests during Emscripten buildStephan Bergmann
...by e.g. executing generated Wasm code with node. This requires check targets to not be skipped unconditionally, unlike for other CROSS_COMPILING builds, so introduce gb_CAN_EXECUTE_HOST_CODE to distinguish these cases. Which revealed that some CppunitTest targets unconditionally used artefacts that are covered by some ENABLE_WASM_STRIP_*, so made those uses conditional accordingly (even though the resulting binaries might actually be dysfunctional, lacking relevant parts; we'll fix that if and when we actually build and run them). Change-Id: I7144eeb908ede25358a3c8186198ac532de4d9f1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166931 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-04-30Emscripten: Only add the --pre-js code to the soffice executableStephan Bergmann
...so that e.g. executing `echo test | node instdir/program/uri-encode.js` doesn't fail with > instdir/program/uri-encode.js:460 > throw ex; > ^ > > ReferenceError: XMLHttpRequest is not defined > at runMetaWithFS (instdir/program/uri-encode.js:312:15) > at callRuntimeCallbacks (instdir/program/uri-encode.js:1882:26) > at preRun (instdir/program/uri-encode.js:913:3) > at run (instdir/program/uri-encode.js:6854:3) > at runCaller (instdir/program/uri-encode.js:6802:19) > at removeRunDependency (instdir/program/uri-encode.js:1060:7) > at receiveInstance (instdir/program/uri-encode.js:1265:5) > at receiveInstantiationResult (instdir/program/uri-encode.js:1281:5) (There's nothing special about uri-encode here, it just happens to be the only other executable that is built into instdir/program/ by the Emscripten build, even if it is probably not even useful there. It expects to read something from stdin, hence the echo part.) (The generic solenv/gbuild/Executable.mk no longer depends on soffice.data.js.link, but it still depends on soffice.data and soffice.data.js.metadata for some cp instructions in solenv/gbuild/platform/unxgcc.mk, so make those dependencies explicit. That can probably be cleaned up further in a next step.) Change-Id: I993878a5f6d19d13728d17e803ae7d773946a1d1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166930 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Tested-by: Jenkins
2024-04-29ofz#68265 fix oss-fuzz build failureCaolán McNamara
Change-Id: I73087235d87253f4c8375fa0c0492c6258701571 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166827 Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> Tested-by: Jenkins
2024-04-26run bison, flex and nasm via wsl in wsl-as-helper caseChristian Lohmaier
Change-Id: Ic3e82b72605cd0b5458bd31ab5ff5285adb3db75 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166340 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2024-04-26initial support for running autogen.sh inside wsl from git-bashChristian Lohmaier
Change-Id: I4272ea817a48880fd4206d6c73add7ccb8c4f6c5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166335 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2024-04-24windows: set CONFIG_SHELL for external configure runsChristian Lohmaier
Change-Id: I9cb03692524eced35935ad1979027f7b196e5ed6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166329 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2024-04-22add undefining FORTIFY_SOURCE to the gcc no-opt flagsCaolán McNamara
We build non-optimized files by adding the no-opt flags to the compiler options that include the optimized flags, so add undefining FORTIFY_SOURCE to the -O0 line motivation here to have --enable-hardening-flags not add unhelpful extra warnings to the build for the parts built with -O0 Change-Id: Ib5416ad7f9f5ef907d7c767a5ebff6343b035cfe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166458 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-04-22com_MSC_class: set MAKE=nmake in gb_NMAKE_VARSChristian Lohmaier
Change-Id: I485a486efba39c12c52d7461f4b235163f009042 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166325 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2024-04-22configure already sets TMPDIR to mixed pathChristian Lohmaier
Change-Id: I72070b054fb505c25f03ff46e7e663d1c1733ad8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166322 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2024-04-22generic is x86_64-specificCaolán McNamara
Change-Id: Ic9912cdebfc75816c54495db4fef68ebeed32c50 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166417 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-04-19Emscripten: Drop unused, deprecated EXPORTED_RUNTIME_METHODSStephan Bergmann
Linking Executable/soffice.html kept warning about > warning: JS library symbol '$allocateUTF8' is deprecated. Please open a bug if you have a continuing need for this symbol [-Wdeprecated] > warning: deprecated item in EXPORTED_RUNTIME_METHODS: printErr use err instead. > em++: warning: warnings in JS library compilation [-Wjs-compiler] printErr had been introduced in f090004c5f236275ca5142fc578f0375872c0336 "WASM adapt link and debug flags" and allocateUTF8 had been introduced in ce60a3dd4dbff0dcb5b82c9053ae5d90f8ac929d "Add LOKit functions and whitelist export for it to WASM", but in both cases no code seems to ever have made use of either of those two methods, before or after. Change-Id: I1e81ca6ddad748d91653f709c272328cc8f2b679 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166296 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-04-19add --enable-hardening-flags to enable compiler hardening flagsCaolán McNamara
distros typically have their own set via C[XX]FLAGS, so make this an optional argument some notes on the options: -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=2 https://www.redhat.com/en/blog/enhance-application-security-fortifysource (I see Fedora has recently bumped to to 3 since Jan 2024 https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags but here use 2 for now instead) -Wp,-D_GLIBCXX_ASSERTIONS https://fedoraproject.org/wiki/Changes/HardeningFlags28 -fstack-protector-strong (We already apply this by default) -fstack-clash-protection https://fedoraproject.org/wiki/Changes/HardeningFlags28 -fcf-protection https://fedoraproject.org/wiki/Changes/HardeningFlags28 https://cgit.freedesktop.org/libreoffice/core/commit/?id=af55dc3891f7950d392175004b2090cb0e54828e and record the compiler flags in debuginfo -grecord-gcc-switches Change-Id: Ib05387bad8324b188bd4ed0ee327d6a7cf83973b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163312 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Andras Timar <andras.timar@collabora.com> (cherry picked from commit 33483058f6e27f39633114721f7329c90571101d) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166289 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-03-22Drop redundant gb_ENABLE_DBGUTILStephan Bergmann
Change-Id: I284e3601ad3d8fe7489e21182a98df40e8d9dbb5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165132 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-03-21Use ENABLE_DEBUG as a better indicator for "debug build"Stephan Bergmann
...than gb_DEBUGLEVEL as had been chosen by 448008d64c643d5a1aa2dc5cccc479efcd709a50 "only enable windows incremental linking for debug builds" Change-Id: Iabd2904596b3ac2a9d1c55d074cc929572615265 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165077 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-03-21Assume this hack is actually needed for --enable-optimizedStephan Bergmann
...and not for whatever dbglevel is set. (The latest claim that this hack is still needed at all is in the 2020-12-14 commit message e0a90aa3239621958bddbb30f98163e8c1ef857f "The workaround for MSVC C4702 is still needed".) Change-Id: Ia73be9417f2d738b0356e36b978beff019388ae1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165073 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-02-24Fix typoAndrea Gelmini
Change-Id: Ibf6edff9b32cb28f5410991493a95d0cc916209d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163872 Tested-by: Jenkins Reviewed-by: Taichi Haradaguchi <20001722@ymail.ne.jp>
2024-02-23Undo "move selection of UNO header variant to platform"Stephan Bergmann
...from 86f4727920ae515987005e3c414f1d6056079be1, as all the platforms define gb_UnoApiHeadersTarget_select_variant in effectively the same way, anyway. (And whether or not any of this actually makes any sense the way it is currently done.) Change-Id: I3b53ed3ee58b1115da31839aba5b2852dfe40920 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163826 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-02-23Fix dead linksMike Kaganski
Change-Id: I5c42fa227401e271bf8d4ce84f42a0667b37a6c4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163803 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-02-23Suppress linker warnings for CLR objectsMike Kaganski
climaker_app.o : /DEBUG:FASTLINK is not supported when managed code is present; restarting link with /DEBUG:FULL Change-Id: Ia4c8ef862999650b317629273996166908232494 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163804 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-02-23Do not suppress newer compiler warnings on WindowsMike Kaganski
This partially reverts commit 133610669b8707a278d9b3b0af025779044fd8c5 (windows: silence new warning for now, 2016-02-21). That commit had disabled warnings introduced after VS 2013 (compiler major version 18). For now, it was impossible to remove the -Wv:18 from CLR flags. Also, some warnings in Boost were suppressed in vcl/source/window/layout.cxx: C:\lo\build\workdir\UnpackedTarball\boost\boost/multi_array/multi_array_ref.hpp(615): error C2220: the following warning is treated as an error C:\lo\build\workdir\UnpackedTarball\boost\boost/multi_array/multi_array_ref.hpp(615): warning C4459: declaration of 'extents' hides global declaration C:\lo\build\workdir\UnpackedTarball\boost\boost/multi_array/base.hpp(69): note: see declaration of 'boost::`anonymous-namespace'::extents' C:\lo\build\workdir\UnpackedTarball\boost\boost/multi_array/multi_array_ref.hpp(612): note: while compiling class template member function 'boost::multi_array_ref<T,2>::multi_array_ref(T *,const boost::general_storage_order<2> &,const __int64 *,const unsigned __int64 *)' with [ T=`anonymous-namespace'::GridEntry ] C:\lo\build\workdir\UnpackedTarball\boost\boost/multi_array.hpp(153): note: see reference to function template instantiation 'boost::multi_array_ref<T,2>::multi_array_ref(T *,const boost::general_storage_order<2> &,const __int64 *,const unsigned __int64 *)' being compiled with [ T=`anonymous-namespace'::GridEntry ] C:\lo\build\workdir\UnpackedTarball\boost\boost/multi_array.hpp(122): note: see reference to class template instantiation 'boost::multi_array_ref<T,2>' being compiled with [ T=`anonymous-namespace'::GridEntry ] C:/lo/core/vcl/source/window/layout.cxx(905): note: see reference to class template instantiation 'boost::multi_array<`anonymous-namespace'::GridEntry,2,std::allocator<T>>' being compiled with [ T=`anonymous-namespace'::GridEntry ] Change-Id: Ibf89e3d3e5a2f6a747bb7fbd214a9b27d8068901 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163717 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-02-22Framework for some UNOIDL to test the Embind UNO binding withStephan Bergmann
It is only built for --enable-dbgutil builds. Load instdir/program/qt_soffice.html in a browser and see "Running embindtest" in its console. For now, it only contains a Test singleton with an empty XTest interface, which is meant to grow additional methods over time. (The code needs to reside in the unotest rather than in the static module, or else the wasm build would run into cyclic dependencies.) Change-Id: I6f65f0c904648a4fd96fc6215c8d59a1544f48a2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163693 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-02-15Fold registeroustring.js into PrimaryBindings.cxxStephan Bergmann
Change-Id: I2e1aa828f194a104d354741518e8cb20015ac276 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163385 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-02-03First-class Embind JS support for OUStringStephan Bergmann
Change-Id: Ic178737da802e17f87d0b5b09004a847b0fe91be Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162956 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-01-29Experimental support for latest Emscripten (and Qt6)Stephan Bergmann
What I'm after in the context of our Embind-related code is the claim at <https://emscripten.org/docs/porting/connecting_cpp_and_javascript/embind.html#memory-management>: "JavaScript only gained support for finalizers in ECMAScript 2021, or ECMA-262 Edition 12. The new API is called FinalizationRegistry and it still does not offer any guarantees that the provided finalization callback will be called. Embind uses this for cleanup if available, but only for smart pointers, and only as a last resort." However, with the recommended emsdk 2.0.31 my tests did not show any use of that finalization support. So I wanted to try with the latest emsdk 3.1.51 instead. But then, linking vcldemo failed with > wasm-ld: error: ~/allotropia-qt5/lib/libQt5Core.a(qlogging.o): undefined symbol: std::__2::__vector_base_common<true>::__throw_length_error() const etc., so I gave it a try to rather build against latest Qt6.7, with > --with-distro=LibreOfficeWASM32 > --disable-qt5 > --enable-qt6 > QT6DIR=... TODO: The result is highly experimental, and it uses ENABLE_QT5 (i.e., the recommended setup with emsdk 2.0.31 and the <https://github.com/allotropia/qt5.git> v5.15.2+wasm branch) vs. ENABLE_QT6 (i.e., my experimental setup with emsdk 3.1.51 and the <https://github.com/qt/qt5.git> 6.7 branch) not only to distinguish between Qt5- vs. Qt6-specific behavior, but also to distinguish between old- vs. new-Emscripten-specific behavior. Of note: * The startup code appears to have changed substantially (and required setting -s MODULARIZE=1 and -s EXPORT_NAME=soffice_entry now, and telling emcc to build just soffice.js and not the wrapper soffice.html. TODO: This also required hacking into qt_soffice.html: (1) The command-line arguments (--norestore, --nologo, --writer, and the exammple.odt; all of which we should eventually get rid of, anyway). (2) Saving the generated instance as window.Module (and adapting the embindmaker-generated code, cf. the changes to static/README.wasm.md). * There were some symbol clashes between external/argon2 and libQt6Core.a(qcryptographichash.cpp.o, so renamed the problematic symbols in external/argon2. Change-Id: I5420ab566d560b11954ac6613249bfc53d8acb31 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162695 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-01-26Use && rather than ; between commands, to not hide errorsStephan Bergmann
Change-Id: I4f8dc3d338b64452dc92c850c7dc174bb59611bb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162592 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-01-23BOOST_ERROR_CODE_HEADER_ONLY doesn't do anything in boost >= 1.69Caolán McNamara
which was released on Dec 12th, 2018 https: //lists.boost.org/Archives/boost/2021/10/252209.php Change-Id: I8d65d98648a44d7303fc46338bfdeba7801749e6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162423 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-01-02Fix Windows path separatorStephan Bergmann
...broken since 84ef6d82546b044990f4efd57e51e29c6c6565c8 "Build external lxml if not provided by system" Change-Id: Ie76c32a1d3094e6d98db7d50195571ae31c0ada6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161536 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2023-12-10Remove hard limit to c89 for clangThorsten Behrens
This seems no longer true: "Windows MSVC only supports C90 so force gnu89" With that said, also do a revert: "external/libeot internally uses --std=c99, do not overrule that" This reverts commit 61a66b612eaeeb38d5d9f9aa83326be6b08c1b6f. Change-Id: Id628131b4fa6b61e19da6d862d773ab36f201729 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160454 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2023-11-22Drop a redundant CR cleanupMike Kaganski
Commit 77779166569da389de44075b3d03413b353046a4 (Remove stray CR from input, 2017-03-09) had introducing the removal of CR from CRLF generated by MSVC's cl.exe -showIncludes. Then, commit e9b9a456221b4b0660f90efa1ee092ea00c2c728 (gbuild: strip away unexpected CR char at the end of Windows filenames, 2017-07-26) added a replacement doing the same, but using a literal CR instead of "\r". It had in its commit message: > seen with 2013 on libreoffice-5-2, but there is no > indication that 2015 on master would be different libreoffice-5-3-branch-point was tagged on 2016-11-23 (commit 4136757b4e51c4e6f7cb4132c95538a7f831ef2c), so the 5-2 branch did not contain the former change, and so the premise that "master would be no different" was likely incorrect. Change-Id: If992eb826c5d6c2868c9bd706ae51847fe69eda7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159754 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-10-27At least use the oldest available -std:c++14 for MSVC gb_CXX03FLAGSStephan Bergmann
...if we don't have a proper -std:c++03 available Change-Id: Iffef738be486b402a2b6af1a2761eb905ac4ddf2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158550 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-04remove obsolete -single_module linker flag (is the default)Christian Lohmaier
has already been unnecessary since over 15 years/was the default since OS X 10.4 (2005) along with ignoring the corresponding altenative (-multi_module) switch, from man ld: -single_module This is now the default so does not need to be specified. -multi_module Multi-modules in dynamic libraries have been ignored at runtime since Mac OS X 10.4.0. This option is obsolete. Xcode 15 now warns about it being obsolete, so remove it. Change-Id: I4d4aab452a330c3c4ec97da4232c3af6350c0ff4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157407 Tested-by: Jenkins Reviewed-by: Patrick Luby <plubius@neooffice.org> Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2023-09-24Adapt a hard-coded value hackStephan Bergmann
...from 22267b7797340d1eb52ced10fe05afeb8a42fc2b "When building with clang-cl, nevertheless use MSVC's CXXFLAGS_CXX11 for CLR" to 1eef07805021b7ca26a1a8894809b6d995747ba1 "Bump baseline to C++20" Change-Id: I817a33b7ca5ae4db232bf4c983d46e808dc83f24 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157230 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-09-18JavaScript uno bindings for WASM with Embind - first cutSarper Akdemir
A rough implementation of uno bindings for LOWA using embind. Adds new parameter '-W' to cppumaker to generate _embind.cxx files alongside .hdl & .hpp. For usage examples see static/README.wasm.md Change-Id: Iee5d05e37bfba8e101c08212b15c05f7f2fa6c33 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156273 Tested-by: Jenkins Reviewed-by: Sarper Akdemir <sarper.akdemir.extern@allotropia.de>
2023-08-28Do a real compile after a successful COMPILER_PLUGIN_TOOL=... compileStephan Bergmann
...so that object files are generated after all, even though the COMPILER_PLUGIN_TOOL=... compile itself doesn't generate them. (This required the existing gb_COMPILER_PLUGIN variable to be disambiguated, by splitting off a new gb_COMPILER_PLUGINS_TOOL variable.) Change-Id: I652c98c9ef2a6120a6e3f809af5ab2ccf09dabc6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156194 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-08-09tdf#155446 Fix problem with ccache on WindowsHossein
This patch fixes the recent problem with building LibreOffice with ccache on Windows which was caused by the lack of double quotation mark between ccache.exe and path to the MSVC compiler. Change-Id: I1a714513ccb8cd674895d0c887013ea862d3b544 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152277 Tested-by: Jenkins Reviewed-by: Hossein <hossein@libreoffice.org>
2023-07-18MSVC: Silence C++23 std::numeric_limits::has_denorm deprecation warningStephan Bergmann
...as seen at least when building against VS 2022 Preview 17.7.0 Preview 3.0 and --with-latest-c++, > [build CXX] connectivity/source/commontools/RowFunctionParser.cxx > workdir\UnpackedTarball\boost\boost/spirit/home/classic/core/primitives/impl/numerics.ipp(199): error C2220: the following warning is treated as an error > workdir\UnpackedTarball\boost\boost/spirit/home/classic/core/primitives/impl/numerics.ipp(199): warning C4996: 'std::_Num_base::has_denorm': warning STL4042: std::float_denorm_style, std::numeric_limits::has_denorm, and std::numeric_limits::has_denorm_loss are deprecated in C++23. You can define _SILENCE_CXX23_DENORM_DEPRECATION_WARNING or _SILENCE_ALL_CXX23_DEPRECATION_WARNINGS to suppress this warning. > workdir\UnpackedTarball\boost\boost/spirit/home/classic/core/primitives/impl/numerics.ipp(193): note: while compiling class template member function 'bool boost::spirit::classic::impl::negative_accumulate<T,10>::add(T &,T)' > with > [ > T=int > ] [...] etc. Change-Id: If9f03e0c5e910549df1c5eb0e089b39623776311 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154552 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-02-24Fix build in a specific VS2022 environmentMike Kaganski
Building libraries in setup_native using VS2022 failed for me reproducibly for some time, with mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "C:/lo/src/build/instdir/program/reg_dlls.dll". The file or directory is corrupted and unreadable. make[1]: *** [C:/lo/src/core/setup_native/Library_reg_dlls.mk:10: C:/lo/src/build/instdir/program/reg_dlls.dll] Error 139 mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "C:/lo/src/build/instdir/program/reg4allmsdoc.dll". The file or directory is corrupted and unreadable. make[1]: *** [C:/lo/src/core/setup_native/Library_reg4allmsdoc.mk:10: C:/lo/src/build/instdir/program/reg4allmsdoc.dll] Error 139 mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "C:/lo/src/build/instdir/program/regactivex.dll". The file or directory is corrupted and unreadable. make[1]: *** [C:/lo/src/core/setup_native/Library_regactivex.mk:10: C:/lo/src/build/instdir/program/regactivex.dll] Error 139 mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "C:/lo/src/build/instdir/program/sdqsmsi.dll". The file or directory is corrupted and unreadable. make[1]: *** [C:/lo/src/core/setup_native/Library_sdqsmsi.mk:10: C:/lo/src/build/instdir/program/sdqsmsi.dll] Error 139 mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "C:/lo/src/build/instdir/program/sellangmsi.dll". The file or directory is corrupted and unreadable. make[1]: *** [C:/lo/src/core/setup_native/Library_sellangmsi.mk:10: C:/lo/src/build/instdir/program/sellangmsi.dll] Error 139 mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "C:/lo/src/build/instdir/program/shlxtmsi.dll". The file or directory is corrupted and unreadable. make[1]: *** [C:/lo/src/core/setup_native/Library_shlxtmsi.mk:10: C:/lo/src/build/instdir/program/shlxtmsi.dll] Error 139 mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "C:/lo/src/build/instdir/program/sn_tools.dll". The file or directory is corrupted and unreadable. make[1]: *** [C:/lo/src/core/setup_native/Library_sn_tools.mk:10: C:/lo/src/build/instdir/program/sn_tools.dll] Error 139 mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "C:/lo/src/build/instdir/program/odbcconfig.exe". The file or directory is corrupted and unreadable. make[1]: *** [C:/lo/src/core/dbaccess/Executable_odbcconfig.mk:10: C:/lo/src/build/instdir/program/odbcconfig.exe] Error 139 mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "C:/lo/src/build/instdir/program/instooofiltmsi.dll". The file or directory is corrupted and unreadable. make[1]: *** [C:/lo/src/core/setup_native/Library_instooofiltmsi.mk:10: C:/lo/src/build/instdir/program/instooofiltmsi.dll] Error 139 mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "C:/lo/src/build/instdir/program/qslnkmsi.dll". The file or directory is corrupted and unreadable. make[1]: *** [C:/lo/src/core/setup_native/Library_qslnkmsi.mk:10: C:/lo/src/build/instdir/program/qslnkmsi.dll] Error 139 mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "C:/lo/src/build/instdir/program/inst_msu_msi.dll". The file or directory is corrupted and unreadable. make[1]: *** [C:/lo/src/core/setup_native/Library_inst_msu_msi.mk:10: C:/lo/src/build/instdir/program/inst_msu_msi.dll] Error 139 It is caused by the -U_DLL and the first entries in gb_Library_use_system_win32_libs: libcmt, libcpmt, libucrt, libvcruntime. They are needed to make the denerated DLLs standalone, not dependent on presence of VCRT on the target system (they are called from installer, when VCRT may not yet be present). It seems to work OK for others, but somehow, this conflicts with the fastlink option on my system, so just avoid it selectively for these DLLs. Change-Id: I61f829682eb051944202bc7ef3578d6f43733030 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147628 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
generated by cgit (git 2.34.1) at 2024-07-12 01:31:00 +0000