setup_native assorted DLLs must have ASAN disabled.
ICU build doesn't work, so disable ASAN for that.
This built with MSVC 2022 and:
CC=...cl.exe -fsanitize=address
CXX=...cl.exe -fsanitize=address
--disable-firebird-sdbc
--disable-skia
--disable-pdfium
Change-Id: I296241e43b68579fdd9b6af9c98a5b541c8ae89a
(cherry picked from commit 98b92b339fa3c28319f3f6cec94abb04229f487a)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194728
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
(cherry picked from commit 579956c4c54f498a22b8e5ed20468ceb9a6e0e30)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194866
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Tested-by: Jenkins
There is no point to bundle it, because
1) it is an old version
2) since LibreOffice 7.5 there are built-in number formats in
Calc with the same functionality (using libnumbertext FWIW)
Change-Id: I8cfb24f7e6f045bd51fea620aca6a61269dba77a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180996
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>
There is no simple "Windows is 10 or newer" check in MSI, with the
Microsoft policy of "you don't need to know real Windows version".
See also https://developercommunity.visualstudio.com/t/detect-a-windows-version-from-msi/412198
The values that MSI sees (e.g. on my Win11) are:
Property(C): VersionNT = 603
Property(C): VersionNT64 = 603
Property(C): WindowsBuild = 9600
So those can't be used for the check. I use the WINMAJORVER that is
read from registry (Software\Microsoft\Windows NT\CurrentVersion).
There is no more need to check and install UCRT; it was dropped.
Change-Id: Ic02d6aeb965e9684bafd4357f969980f77000e73
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178049
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
…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>
(Thanks to Mike Kaganski for noticing the gotcha here that a naive replacement
with
> std::wstring(const wstring& str, size_type pos)
would do something rather different than
> std::wstring(const wchar_t* s, size_type n)
does.)
Change-Id: I78837c014cdc154f276db1a11a87aaf74319a9fc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159114
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Using the mdls command fails if macOS Spotlight is disabled for the path
selected by the user. So, instead, check if the path contains a matching
"ProductKey=<version>" line in its Contents/Resources/bootstraprc file.
Change-Id: Idbf8e2712b9fae8efa0997cf5c5c0f3fa6e68658
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154718
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Reviewed-by: Patrick Luby <plubius@neooffice.org>
These routines can fail during MSI installation
(seen leftover program_old folders, with program folder missing).
We at least want to see the error in the MSI log file when this doesn't succeed.
This outputs error messages like:
MSI (s) (C4:5C) [10:47:54:280]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI37B4.tmp, Entrypoint: RemovePrgFolder
CustomAction RemovePrgFolder returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 10:47:54: RemovePrgFolder. Return value 3.
Change-Id: I4ce4099eeb3e0ee79eb4a2e1d3887f9810fd9669
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134160
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
Do not bundle LanguageTool which is at a 10 year old version (1.7)
while upstream has a lot of new releases (now at version 5.5.x)
It is not bundled by any downstream distributions
so it makes no much sense to keep it integrated here.
Change-Id: Icd2ef151b1b8d0252ffa3db0caaba576f2783fa9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133356
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
...which defines NULL as a plain 0 integer literal instead of the GNU __null
extension, so clang-cl's -Wnull-conversion cannot kick in. These findings are
from an experimental build done with clang-cl and a modified
> --- a/clang/lib/Headers/stddef.h
> +++ b/clang/lib/Headers/stddef.h
> @@ -83,6 +83,10 @@ typedef __WCHAR_TYPE__ wchar_t;
> # if !defined(__MINGW32__) && !defined(_MSC_VER)
> # define NULL __null
> # else
> -# define NULL 0
> +# if __cplusplus >= 201103L
> +# define NULL nullptr
> +# else
> +# define NULL 0
> +# endif
> # endif
> #else
> # define NULL ((void*)0)
However, that build also ran into lots of places where 3rd-party code in
external/ and Windows system headers caused issues when NULL is nullptr (which
I worked around with various hacky patches for that build), so this is
unfortunately not something that can easily be enabled generally.
Change-Id: I10674464498a9bc63578d9e6cc32ddde23ab4f30
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124419
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
First, Extension_nlpsolver is not unconditionally covered by --with-java, but by
a dedicated --enable-ext-nlpsolver (which requires --with-java). (I had
overlooked that the whole Module_nlpsolver is conditional in
RepositoryModule_host.mk.) So the check for Extension_nlpsolver should instead
check for NLPSOLVER in BUILD_TYPE.
Second, the check for --enable-ext-numbertext could check for NUMBERTEXT in
BUILD_TYPE instead of checking for NUMBERTEXT_EXTENSION_PACK, as
--enable-ext-numbertext sets both (cf. m4/libo_check_extension.m4).
And third, any --enable-ext-* will set WITH_EXTRA_EXTENSIONS (cf.
m4/libo_check_extension.m4), so all those various BUILD_TYPE checks can all be
subsumed by a single WITH_EXTRA_EXTENSIONS check. (Which nicely reduces the
maintenance burden mentioned in the commit message of
f267340d30 "Remove unused
$(LIBO_SHARE_FOLDER)/extensions/package.txt.")
Change-Id: Ifdf8b59febd49661500292ab2003c792d8cb60a7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120104
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...even if unused, as otherwise a minimal --without-java build (i.e., where the
ifeq in setup_native/Package_packinfo.mk actually triggers) failed with
> setup_native/Package_packinfo.mk:18: *** gb_Package__check: Package setup_native_packinfo has not been defined. Stop.
Change-Id: I0fa3640448da333294ee2ab25183df1ffee22533
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120094
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
There had originally been some back-and-forth among
134ae5da1c "jl154 #162868# remove
basis/presets/bundled/bundled.ini, and create always share/extensions folder",
4c333e8ac7 "jl154 #162868# removing the
package.txt from the extensions folder. Extensions folder will be created in a
different way than installing a dummy file", and
8f4cf9a16e "jl154 #162868# guarantee existence of
extensions folder" whether or not that dummy file was necessary to ensure
creation of the (otherwise potentially empty) $(LIBO_SHARE_FOLDER)/extensions/
directory. That is no longer necessary with gb_Package_add_empty_directory
(though the logic that had to be added to setup_native/Package_packinfo.mk now
is a bit unfortunate, and will need to be updated whenever the list of potential
bundled extensions changes).
(And that dummy package.txt file is apparently not used to track whether per-
user extension information needs to be updated when the contents of
$(LIBO_SHARE_FOLDER)/extensions/ changes. That is rather done by
comparing the status of the $(LIBO_SHARE_FOLDER)/extensions/ directory itself
against user/extensions/bundled/lastsynchronized in the UserInstallation, see
needToSyncRepository in desktop/source/deployment/misc/dp_misc.cxx.)
Change-Id: I5b9956c508288945f32a88afaef57ac0b63dc27f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120081
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
* Updated README.md contents to fix various issues
* Fixed source links by using [git:], processed by mkdocs scripts
* Added README.md for ios, setup_native, unotest
* Fixed issues with "underline" and "less than" sign
Change-Id: I3e52a1d3372586c390ee6c42a2ef48bbabc81398
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114248
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
kMDItemDisplayName has different values depending on the setting whether
to show extensions for all filetypes in Finder, breaking the
detection/validation of the installation target in case the user doesn't
use the default setting.
Change-Id: Ic9605abaaa1f070f1f5ec9940190fd1dd2555bdf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110479
Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
OOODOWNLOADNAME was set in the global section of openoffice.lst, so the
code always did set the target path with set_download_filename. Thus
remove the superfluous sub and then also the no longer used
OOODOWNLOADNAME variables
In the same vein: the "script that extracts a tarball that is appended
to it" method is no longer in use since many years, delete that as well.
Change-Id: I43481a3ec09e064ef77138e1cbfc1dba6854f2d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110017
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Annoyingly the packinfo_*.txt don't support conditionals but we can
work-around that with a little duplication.
Change-Id: Id00a6831effcc63a917fc21d2cd201474fdb559d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109569
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Xisco Fauli