summaryrefslogtreecommitdiff
path: root/solenv/gbuild/platform/com_MSC_class.mk
AgeCommit message (Collapse)AuthorFilesLines
2024-03-22Drop redundant gb_ENABLE_DBGUTILStephan Bergmann1-1/+1
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 Bergmann1-1/+1
...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-02-23Undo "move selection of UNO header variant to platform"Stephan Bergmann1-8/+0
...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-01-02Fix Windows path separatorStephan Bergmann1-1/+1
...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-08-09tdf#155446 Fix problem with ccache on WindowsHossein1-2/+6
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-02-24Fix build in a specific VS2022 environmentMike Kaganski1-3/+4
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>
2022-12-13gb_var2file: remove now unused chunk-size parameterChristian Lohmaier1-3/+3
that parameter did specify how many entries of the list the workaround method could use to not exceed commandline length limits, so it was a guess of sorts and many places didn't actually bother with tweaking that value anyway and just used 100. the $(file …) function doesn't care about that, so the parameter was always ignored in that case. Change-Id: If89ec3a1968be297c0fe7c65336c5a965598f0c9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143911 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2022-10-19Make MSVC -showIncludes processing more reliableStephan Bergmann1-1/+2
With the Windows display language set to "Portuguès (Brasil)" (and the corresponding Visual Studio language pack installed), configure.ac detected SHOWINCLUDES_PREFIX to have the value "Observação: incluindo arquivo:" in UTF-8 (i.e., with bytes ... C3 A7 C3 A3 ...). However, for whatever reason filter-showIncludes.awk apparently didn't manage to match the input it receives against the value of that environment variable, and the Cygwin terminal contained output lines starting with either > Observa□ao: incluindo arquivo: (with toplevel plain `make`, plain `make` in a module, and `make -O` in a module) or > Observaçao: incluindo arquivo: (with toplevel `make -O`). (Note how "ç" is either garbled as "□" or shown correctly, and "ã" is always shown as plain "a".) It's not quite clear to me where exactly this garbling happens, and why the behavior is apparently different in configure.ac vs. make. The most reliable way to avoid these issues altogether is to force MSVC to emit English diagnostics, via VSLANG=1033, as explained at <https://stackoverflow.com/questions/2286216/how-to-change-msbuild-error-message-language>. (I didn't find any official documentation of that environment variable on MSDN though. Thanks to Mike Kaganski for providing that Stack Overflow link.) dfbce2a556972f552d194d2358c170077915d776 "gbuild: try to run filter-showIncludes.awk in C locale" had started to call that AWK script with LC_ALL=C (and subsequent commits had copied that LC_ALL=C in calls to similar AWK scripts). But that appears to neither be sufficient (see above) nor necessary now, so I removed all those LC_ALL=C settings. (There is a gawk --characters-as-bytes option, but trying that out didn't make a difference for this issue.) clang-cl doesn't support VSLANG, nor does it generate localized diagnostics in the first place, but lets consistently add VSLANG=1033 when determining LO_CLANG_SHOWINCLUDES_PREFIX in configure.ac, too. (The way VSLANG=1033 is set in gb_CObject__compiler in com_MSC_class.mk, it affects all kinds of MSVC and clang-cl invocations, whether or not they actually honour that environment variable.) Change-Id: I52d0e842d200ed256a44d6cc5de1b3868c0acc71 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141524 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-04-12Delete tempfile when doneStephan Bergmann1-1/+2
Change-Id: Ide7acab1ab8eae760f9818248ce44d07ca92a6f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132884 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-01-23tdf#97046 prefix gb_ to system variablesArjun1-2/+2
Change-Id: I8be2f55e3306d7ac34ea5819ab93fd537315b281 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128804 Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org> Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2022-01-01gbuild: silence Windows Skia clang buildsJan-Marek Glogowski1-0/+2
When building Skia on Windows in an non-English environment, the console is filled with "Note: including file:" output. That's because cl.exe has some translated output, but clang.exe has not. So detect the clang usage and its "showIncludes" output and override that setting for the compiler call. Change-Id: I19b403aa79a8dde70616865aef051aa365f79de6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127822 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-12-31gbuild: introduce gb_%_linktarget_targetJan-Marek Glogowski1-1/+1
Just some refactoring. Change-Id: I47adb93f8a413d289f6abb2a48ed3f049f582a46 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127799 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-12-01apparently link.exe -dump is a short for dumpbin.exeLuboš Luňák1-2/+2
So use the latter, in case we'll want to use lld-link, as that one doesn't know -link. Change-Id: I35e05064da06741cae1aa267b455e22741fef090 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126157 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-30use -fno-pch-timestamp also with clang-clLuboš Luňák1-0/+9
Change-Id: Ib985a22040a3cebea5ccb303576065a48f73d3ee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126112 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-29clang-cl: do not complain about precompiled_xxx.hxx includeLuboš Luňák1-1/+2
It was complaining about the header being found using non-standard Microsoft seach rules. Change-Id: I1872515b638f4181b32126c8a932105fdcbdb9f1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126023 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-17support ccache for MSVC tooLuboš Luňák1-2/+16
There's no official MSVC support in ccache yet, but there are patches in progress of getting upstreamed. So right now it's necessary to get a patched ccache. Ccache cannot work with -Zi option, since sharing debuginfo in a .PDB cannot be cached. Added --enable-z7-symbols that gets enabled by default if ccache is detected. It works even with PCHs enabled, and externals seem to work too. I get almost 100% hit rate on a rebuild, although such a rebuild is slower than on Linux. Change-Id: I1d230ee1fccc441b9d9bec794cc2e1ec13161999 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125179 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-13do not rebuild PCHs on icecream/ccache changeLuboš Luňák1-5/+7
We turn -Wunused-macros on or off depending on whether icecream/ccache are used, and since now PCHs rebuild on CXXFLAGS changes, a plain temporary 'CCACHE_DISABLE=1' caused a rebuild. Change-Id: I63d539ac037d595f76a39e585011d1fde54f7f20 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125125 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-04Resolves: tdf#97046 ensure build system variables start with gb_Sabyasachi Bhoi1-3/+3
Change the variable name: var2file to gb_var2file Change-Id: Ib7d64b76cfe10e6c2df1a176674a360b28704070 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124666 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-11-03fix gcc-wrapper for ccache.exeLuboš Luňák1-2/+2
This reverts a part of 18cc01b63996f81b284e3bc827d1be7f3da8983a . Change-Id: Ib7abbc41eeb6abd573f540ae2d0d2822e68b9abb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124613 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-01remove unused gb_CObject__command_pattern parameterLuboš Luňák1-2/+2
Usage removed in bc39f6b0e62b0a54500bf3986f971a43fe8f843d . Change-Id: Ie2d8782f84ae39360698885d238ec2154a5b0d82 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124533 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-10-31fix usage of MSVC's -debug:fastlinkLuboš Luňák1-1/+6
Using /link while only compiling does nothing (and MSVC apparently doesn't bother to warn). Fix gbuild to pass -debug:fastlink when linking, and limit it to dbgutil builds, since pdb files cannot be moved elsewhere if the option is used. Change-Id: I0325c55ddea1ce881b60b1373c81019d154ef672 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124526 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-10-30upgrade libjpeg-turbo to 2.1.1Caolán McNamara1-0/+1
simd enabled for x86_64 and x86, arm/aarch64 might be worth exploring too Change-Id: Ic2726ee8c6b6e59ca983b977ee2731f5b78b97d1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123898 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-10-13MSVC LTO does not like mixing 32bit and 64 codeLuboš Luňák1-2/+2
So disable LTO for x64 code when building for 32bit. Change-Id: I8445d8307b3b797b78cea12e6322e0d792c71dfd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123537 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-09-22avoid some more D9025 warningsLuboš Luňák1-15/+21
Change-Id: I01f8df5f399b17f46da9a59501bea28bc70cac4e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122431 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-09-20use MSVC's /Zc:inline option to reduce binary sizeLuboš Luňák1-1/+2
If I'm getting it right, MSVC has a non-conforming feature that allows to declare a function as inline without defining its body in the header, and it'll work if the function is actually emitted elsewhere, and the linker will sort it out. This seems to be implemented by forcing emitting of out-of-line copies of all inline functions, which is wasteful. /Zc:inline disables this useless feature, which seems to save quite some space (optimized build, starmath's .o files 350k->220k, smlo.dll 2.5M->2.2M). The docs don't say anything about binary compatibility, but treat it the same way as -Zc:dllexportInlines, just in case. This change also may help avoid the tdf#144598 problem for our AVX/etc. code, such as in Calc. Change-Id: I73cc5d46ba1e4245e8d3b6688804c2b9684d2f9a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122334 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-09-20use clang-cl's -Zc:dllexportInlines- for clang-cl buildsLuboš Luňák1-2/+3
This is clang-cl's equivalent of -fvisibility-inlines-hidden, and it seems to be also sort of the equivalent of MSVC's -Zc:inline. So it saves build time and disk space. Clang docs say that this is binary compatible in only one direction, so our public C++ code shouldn't be using this, as external C++ code could try to use exported inlines that are no longer there. Change-Id: Ie6217808f8ee4a15344183abfc65038e1558d1b0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122352 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-08-04Always provision PATH the cygwin way under WindowsThorsten Behrens1-4/+0
With PATH essentially serving the role of LD_LIBRARY_PATH under Windows, there was the notion that this needs to be provided in Windows notation, for win32 gnumake. That was perhaps once true; currently we're always evaluating PATH inside a shell, not the Makefile. So this since a while only worked accidentally, due to cygwin transparently converting between DOS and UNIX PATH vars. It did break though for corner-cases, e.g. SRCDIR!=BUILDDIR, and BUILDDIR e.g. D:\FOO. With that simplification, also GNUMAKE_WIN_NATIVE can go. Change-Id: Ied5a0443dc70e7dc629c0c0620e6ce911d9a73d0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119941 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2021-05-29gbuild: implement gb_Library_get_target_for_buildJan-Marek Glogowski1-0/+1
I was wondering why removing instdir stuff forced a rebuild of the cross toolset. Turned out some cross-toolset bits were wrongly depending on host build stuff. It even had FIXME... As a consequence, gb_CPPU_ENV was replaced by config_host.mk flags to provide an CPPU_ENV_FOR_BUILD and also uses the correct OS_FOR_BUILD. Change-Id: I50e8e8dca50ab1ad3164948a585a792a52e4a39a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116359 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-04-03Add initial support for sccache builds on WNTThorsten Behrens1-2/+2
- gets auto-detected if an sccache binary is in the path - currently external projects using gcc-wrapper are _not_ cached - this needs fixing in the gcc-wrapper - current sccache versions won't work with -Fp (precompiled headers), so while sccache gets called, nothing really is cached. Best build with --enable-pch=no therefore. Change-Id: I78dd7e08ea20ae888236c8c8e8e7a25a405f23b5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113530 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2021-03-23Rename LO Windows arm64 ID to aarch64Jan-Marek Glogowski1-3/+3
The Windows platform is called Arm64. But now that the ID for Mac is also going to be renamed from arm64 to aarch64, this get's rid of the arm64 as the UNO identifier and user in gbuild, just like on all other Arm64 platforms. Change-Id: I60a7eafd04b426f17b6e41ad9a09e6405c0d4173 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112973 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-02-26WIN don't use --wrapper-print-cmdline in verboseJan-Marek Glogowski1-2/+2
This breaks configure, as it fails the check: "gcc-wrapper.exe --wrapper-print-cmdline supports -c -o file.obj... no" That's because that cmdline is written to stderr, but that check also tests for the stderr output and diffs it with some linker boilerplate, which definitly has a different command line, so there is practically no way to use that flag with configure. I'm not sure how that even passed here. Even a current autconf still produces the same check code then the old libjpeg-turbo configure script already contains. Regression from commit 4108665b63ab432732b8b351568c255d872cc3ff ("WIN cross: fix gpg-related library builds"). Not sure, if I should drop the whole flag.... Change-Id: Ie01b00c5890c66479c33c61589366ce35cc783ba Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110962 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-30Fix typosAndrea Gelmini1-1/+1
Change-Id: Ie6146de848b7c5bb7a8edc76a0652c9c623b7024 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103723 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
2020-09-30bridges: add a Windows Arm64 UNO bridgeJan-Marek Glogowski1-0/+16
Since Microsoft follows the general ARM64 ABI calling conventions, and the SEH exception handling is the same, this result is a mixed port of the gcc3_linux_aarch64 bridge and the refactored x86-64 exception handling. I have no idea, if the complicated 32-bit handling in RaiseInfo() is needed, as the ARM64 trampolines definitly use 64-bit code. But since this is the first working version, I currently don't mind much ;-) There is definitly more potential for refactoring in the whole bridges directory... Change-Id: I9782a2e99c0231cdd1286af156ad312229eccf39 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103642 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-24Expand the Windows CPPUNITTRACE=TRUE abbreviation in placeStephan Bergmann1-1/+1
...as a means towards defining gb_CppunitTest_GDBTRACE only in a single place (in solenv/gbuild/CppunitTest.mk), which should make reasoning about the code simpler Change-Id: I1a587ee08deb4e969e615b2544265b2ba34bd8af Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103296 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-16configure + gbuild: handle Windows Arm64Jan-Marek Glogowski1-1/+1
Change-Id: Idfc20c1234d693d6b402158b8bc782bd17cd3f4b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102850 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-11WIN cross: fix gpg-related library buildsJan-Marek Glogowski1-2/+2
Cross compiling these libraries requires to supply the cross- compiler via the CC_FOR_BUILD environment variable. Since we have to use the gcc-wrappers, we now need two different invocations with different inclues and libraries, but just have fixed environment variables. Also, the CC_FOR_BUILD clashes with LO's own variant, but that is easy to fix. So this change includes: - gcc-wrappers: new option --wrapper-env-prefix to add a prefix to the environment variable names - gcc-wrappers: new option --wrapper-print-cmdline to dump the real command called, when a verbose build is executed - gcc-wrappers: default to exe, if the output has no extension - unify build flags for gpg related libraries Change-Id: I4e6a6ba3c6e09237c8ffefa40ce61131290a3852 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102482 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-11Fix the minimal build-tools targetJan-Marek Glogowski1-6/+7
The revert commits change the build-tools target for a DESKTOP build to build the complete LO. This restores the original, minimal one and also adds a whitelist of allowd build types. OpenCL needs a configure switch, as it's status is also stored in a config header, so preventing the build is not enough. This also reverts: - commit 802161a505272732566210e9ebbd8fe1b23fb86d - commit 02d931a59e2966d0c2736db8dee7be3e3dcd6bae Change-Id: Ibfcb0c54e72da1b7c2e63c082ea6586520a787fa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102480 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-08-12Enable --enable-lto --enable-skia when building with GCC+Clang on LinuxStephan Bergmann1-1/+1
...where all the Library_skia objects are built with Clang, so contain intermediate LLVM bytecode, but were then linked via GCC and ld or gold, which do not understand such object files and thus failed. So in gb_LinkTarget__command_dynamiclink use T_CC/T_CXX also for the linker command line. But then Clang would still be used for linking with the -fuse-ld=(ld or gold) $(USE_LD) suitable for GCC, and would still fail. So break T_USE_LD out of T_LDFLAGS and let gb_LinkTarget_use_clang override T_USE_LD with CLANG_USE_LD. At least for now, that CLANG_USE_LD (containing something like -fuse-ld=lld or -fuse-ld=lld --ld-path=... for the latter see d668c9a04d04d256fcbbd2165fe226f1db88256b "Adapt --enable-ld to Clang 12 trunk --ld-path") needs to manually be passed into autogen.sh, it is not computed in configure.ac. Then building Library_skia would still fail to link against StaticLibrary_libpng, as that only contains intermediate GCC object code, so make sure to build it with -ffat-lto-objects in this specific case. Change-Id: I0a104e53a8898cd9c2eb3b643e21954e853608cc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100556 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-05-07no longer force -arch:SSE on WindowsLuboš Luňák1-5/+5
SSE2 has been pretty much a requirement for running Windows since about 2018, so there should be ~nobody needing this. https://lists.freedesktop.org/archives/libreoffice/2020-May/085029.html Change-Id: I579eb92c18e42c57aa1421b889cfa7997b84915f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93558 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-6/+8
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-06use full path for the PCH .hxx file for MSCLuboš Luňák1-2/+3
Microsoft cl.exe actually doesn't care, but clang-cl without this complains that it cannot find the .hxx file for the PCH. Change-Id: Ic2db94f2323ddb884ea71e6ac6554cc0a5ab682a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91744 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-03-27revert the gyp-based nss build changesLuboš Luňák1-1/+1
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-23do not reset PATH when invoking internal pythonLuboš Luňák1-1/+1
Change-Id: I7759fefbf5c2dbc39ae9a53f7c044bf63165608c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90116 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-03-23configure,gbuild: gla11y fails on Fedora 31Michael Stahl1-1/+1
The problem is that the LD_LIBRARY_PATH on the command line causes /usr/bin/python to find LO's libpython*.so*: 18269: find library=libpython3.7m.so.1.0 [0]; searching 18269: search path=.../instdir/program (LD_LIBRARY_PATH) 18269: trying file=.../instdir/program/libpython3.7m.so.1.0 Presumably LD_LIBRARY_PATH is used to find bundled libxml/libxslt. So let's try to disable the broken case where a bundled lxml is used with system python and bundled libxml/libxslt; this cannot work. (regression from 84ef6d82546b044990f4efd57e51e29c6c6565c8) Change-Id: I67aa8250691cae8f899d65f674aa9da23a9d1d7a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90906 Reviewed-by: Samuel Thibault <sthibault@hypra.fr> Reviewed-by: Michael Stahl <michael.stahl@cib.de> Tested-by: Jenkins
2020-02-16GBUILD_TRACE, support for finding out where the build time is spentLuboš Luňák1-1/+10
See instructions in solenv/gbuild/Trace.mk . This generates a file than can be viewed e.g. in the Chromium tracing view. Change-Id: I5f90647c58ca729375525b6daed2d4918adc8188 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88754 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-01-20only enable windows incremental linking for debug buildsNoel Grandin1-1/+3
not necessary for optimised builds Change-Id: I33e7ff372b8b2fd35d6d45b552aceda36aaeba95 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87054 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-01-09Get PDB files to work for soffice.bin and unopkg.binJuergen Funk1-1/+1
..by renaming them to *.bin.pdb, so WinDbg picks them up. Follow-up fix to commit 6ca3adf22b62b88b313c8fc9311183efdabe445a Change-Id: I5cb7b305c997b423cf0cd70835163811f75b3e25 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86465 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2019-12-19Fix typo in codeAndrea Gelmini1-3/+3
Change-Id: I7c71e16628819bd60664f9b4dc70f0f0762afb48 Reviewed-on: https://gerrit.libreoffice.org/85521 Reviewed-by: Michael Stahl <michael.stahl@cib.de> Tested-by: Jenkins
2019-12-07Remove redundant gb_YACC indirectionStephan Bergmann1-1/+1
(as discussed at 0a803c0a41f46be4019ddd2768b4be5669b7ab59 "Honor BISON passed into configure") Change-Id: I160a3c97414be47cd1efef0b7fac4af93a398ac6 Reviewed-on: https://gerrit.libreoffice.org/84684 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-04tdf#128133 WIN don't exit after link-output filterJan-Marek Glogowski1-1/+1
The linker output filter command (gb_filter_link_output) ends with an exit "${PIPESTATUS[0]}", which will quit the current Makefile shell command always after calling the linker. This prevents the later shell code of that line to run, which includes the merge of the DeclareDPIAware.manifest. That manifest would tell Windows that LO binaries are "<dpiAware>true</dpiAware>", to prevent System DPI scaling. Since it's not merged, LO is scaled by the OS, resulting in blurry fonts. Since there is no reason to have an extra make "function", like ifeq or multiple definitions, this includes the code directly. Additionally the MS linker has localized output, so this patch uses a more generic regexp to filter-out the default link message, which works with the English and German locale. Change-Id: I0099f6c38ca0eda18c7b0c108529bc73189c1504 Reviewed-on: https://gerrit.libreoffice.org/84099 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-20 05:24:01 +0000