Hallo Christian,
Christian Lohmaier schrieb am 29.04.2025 um 12:47:
Hi Regina, *,
On Mon, Apr 28, 2025 at 8:02 PM Regina Henschel <rb.hensc...@t-online.de> wrote:
Ilmari Lauhakangas schrieb am 28.04.2025 um 15:35:
On 4/28/25 16:32, Regina Henschel wrote:
[..]
If you use LODE, run `git pull` in LODE and then `./setup`
I have now tried it with WSL. With that and autogen.input
[…]
I get the warning:
* WARNING : please add PKG_CONFIG=/path/to/pkgconf-2.4.3.exe to
autogen.input or put it in PATH, a windows version of pkgconf is
required to build harfbuzz
A file pkgconf-2.4.3.exe does not exist.
So with the WSL build environment there is a problem with harfbuzz too.
Well, not really a problem, just a matter of new dependencies,
you can use the winget configuration to fetch the dependencies/use
those as a template as to what to do:
https://git.libreoffice.org/core/+/refs/heads/master/.config/admin_java_and_deps.winget
downloads the deps (i.e. you'll find the URLs in there if you want to
do it manually), and
https://git.libreoffice.org/core/+/refs/heads/master/.config/user_steps.winget
extracts stuff.
So for pkgconf: It is available as a pre-built and you're expected to
put it into your PATH, ~/bin for example in case of git-bash will do.
If you don't put it into path, you need to add PKG_CONFIG=<path> to
autogen.input to tell it where to find it, needs to be a path that wsl
can resolve, so windows path or a unix-path as seen from wsl (e.g.
/mnt/e/lo/pkgconf-2.4.3/build/pkgconf.exe or
E:/lo/pkgconf-2.4.3/build/pkgconf.exe) – but it should be picked up
from PATH if you call it pkgconf-2.4.3.exe.
Meson is simply extracted, and for wsl-as-helper case there's no
attempt to auto-detect the location, so for that you'll have to
specify it in autogen.input with MESON=<path/to/meson.py> – again in a
form that wsl can resolve properly, so either windows-path or
path-as-used-within-wsl, e.g. E:/lo/meson/meson-1.7.2/meson.py
The same pkgconf and meson is used for both cygwin and wsl-as-helper builds.
With adding these files and adapting the autogen parameters, the build
with Cygwin works now.
But build with WSL still does not work. I have added the files and
adapted autogen.input. It is now:
--enable-dbgutil
--with-visual-studio=2022
--without-lxml
--disable-ccache
--with-jdk-home=C:/BuildLOAdds/jdk
--enable-python=fully-internal
--with-junit=C:/BuildLOAdds/junit/junit-4.10.jar
--with-ant-home=C:/BuildLOAdds/apache-ant-1.9.5
--with-strawberry-perl-portable=c:/BuildLOAdds/Strawberry
--host=x86_64-pc-cygwin
--with-external-tar=C:/BuildLO3/externalsrc
--with-doxygen=C:/BuildLOAdds/Strawberry/c/bin/doxygen.exe
--enable-odk
PKG_CONFIG=C:/BuildLOAdds/pkg/pkgconf-2.4.3.exe
MESON=C:/BuildLOAdds/meson/meson-1.7.2/meson.py
Now the call
wsl ./autogen.sh
does no longer produce errors.
But when I start a build with
~/bin/make
it comes to the line
C:/Users/user/bin/make -j 32 -rs -f C:/BuildLO3/core/Makefile.gbuild build
and hangs there for ever.
So there is still something wrong. Any idea where to look for?
(ninja is assumed to be part of Visual Studio installation, the cmake
tools for windows which are installed by default if you pick c++
desktop development, but if you did a manual/minimal installation
without implied/recommended packages you might need to add that
manually)
ninja.exe exists as
"C:\Program Files\Microsoft Visual
Studio\2022\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\Ninja\ninja.exe"
Kind regards,
Regina
