Build problem because of harfbuzz

[Regina Henschel]

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.henschel at 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