AW: Trouble with new lo-build

Thu Jul 3 10:08:19 UTC 2025

Hi Christian Lohmaier,

> For macOS (and wsl-as-helper) build autogen.sh was modified to use the
> replacements from the m4/mac directory. So to remove pkgconfig from
> the cygwin installation list, that also would be necessary for plain
> cygwin.

That was only a Idee.

> you could use both wsl1 and wsl2, no nested acceleration features
> necessary to build LO (but are nice if you need ipv6 networking from
> the wsl host or similar) - the vast majority of the build is run
> completely on the windows side. you only need the wsl container to run
> configure (LO's own and of some externals) and run flex, bison, nasm
> gperf, zip (and if building with translations msgfmt & msguniq) –
> stuff that's only used a handful of times..

When i try to install with wsl --install
i get the error (sorry is in german)
Herunterladen: Ubuntu
Wird installiert: Ubuntu
WSL2 wird von Ihrer aktuellen Computerkonfiguration nicht unterstützt.
Aktivieren Sie die optionale Komponente "Plattform für virtuelle Computer", und stellen Sie sicher, dass die Virtualisierung im BIOS aktiviert ist.
Aktivieren Sie "Plattform für virtuelle Computer", indem Sie ": wsl.exe --install --no-distribution
" ausführen. Weitere Informationen finden Sie unter https://aka.ms/enablevirtualization
Fehlercode: Wsl/InstallDistro/Service/RegisterDistro/CreateVm/HCS/HCS_E_HYPERV_NOT_INSTALLED
Aktivieren Sie "Plattform für virtuelle Computer", indem Sie ": wsl.exe --install --no-distribution <- not slove the problem
The main problem is, it need the Hypervisor but it run in Hyper-V and in this case need the nested virtualisation.
Maybe try again and set a new environment under Windows 11 as host, after Microsoft the nested virtualization should then be activatable

> lode/instructions use junit 4.10 for simplicity, since that contains
> both files, and the vulnerabilities it has are of no interest for CI
> or when building (only) LibreOffice.
> Since you already specify separate jars, you could use a more current
> junit that doesn't have the related vulnerabilities.
Is it sufficient if i only use junit 4.12?

> So what do you mean with "the confuse output it is the same without
> color" - so even in a "confused" = mixed result you don't get actual
> color but the color control characters are printed to the screen
> instead?

When you look to the starting Email here, you can see the mixed output,
the call was /opt/lo/bin/make gb_COLOR=1
but when call /opt/lo/bin/make
then is not with color but the output the same (without the color control characters)

> Anyhow, the first time hearing about this kind of problem, and no idea
> where else to look. If you don't have gb_COLOR set, and also not
> MSYSTEM, then there should be no color to begin with. You can try to
> delete the gb_COLOR=$(true) line from solenv/gbuild/Output.mk to make
> sure it isn't set by the build itself. (or you can try make gb_COLOR=1
> to see whether that makes a difference)

I think maybe the problem is that this build system runs in Hyper-V

Jürgen

________________________________________
Von: Christian Lohmaier <lohmaier at googlemail.com>
Gesendet: Mittwoch, 2. Juli 2025 16:13
An: Juergen Funk
Cc: libreoffice at lists.freedesktop.org
Betreff: Re: Trouble with new lo-build

Hi,

On Wed, Jul 2, 2025 at 2:00 PM Juergen Funk <j-funk at outlook.de> wrote:
>
> if I understand this correctly, then we can actually remove the pkgconfig from the cygwin dependencies, because it cannot be used.

Theoretically – pkgconfig is still needed to provide the corresponding
m4 macros so that configure can be generated from configure.ac

For macOS (and wsl-as-helper) build autogen.sh was modified to use the
replacements from the m4/mac directory. So to remove pkgconfig from
the cygwin installation list, that also would be necessary for plain
cygwin.

> > Then you might also have used the wsl-as-helper approach as opposed to
> > using cygwin.
> I wanted to use wsl but have (host) Win10 there Hyper-V in that it runs with (guest) Win11 the buildsystem. But because it needs the nested (in hyper-v) virtualization the host must also be Win11

you could use both wsl1 and wsl2, no nested acceleration features
necessary to build LO (but are nice if you need ipv6 networking from
the wsl host or similar) - the vast majority of the build is run
completely on the windows side. you only need the wsl container to run
configure (LO's own and of some externals) and run flex, bison, nasm
gperf, zip (and if building with translations msgfmt & msguniq) –
stuff that's only used a handful of times..

> > Junit 4.10 should still include hamcrest, so if you're already using
> > the separate hamcrest you could/should also be using newer junit
> > probably...
> am now a little confused should be using  of junit 4.13 with hamcrest 2.2?

lode/instructions use junit 4.10 for simplicity, since that contains
both files, and the vulnerabilities it has are of no interest for CI
or when building (only) LibreOffice.
Since you already specify separate jars, you could use a more current
junit that doesn't have the related vulnerabilities.

For running the LibreOffice tests there is no difference.

> I can build and it takes 30 min for the complete build
>
> > MSYSTEM is only set in git-bash (i.e. in the wsl-as-helper method),
> > not in the default cygwin terminal, so unless you manually set
> > gb_COLOR to true (something non-empty), it should not use colored
> > output to begin with.
> In cygwin i never using the cygwin-git, it is faster with Git for Windows, but
> the bulid is in cygwin and the confuse output it is the same without color
> but the autogen.sh output is correct.

I don't quite get that last part, so you're using git-bash for git
operations, but run autogen.sh / the build within cygwin terminal
only. autogen.sh doesn't use color, so that should be always OK.

So what do you mean with "the confuse output it is the same without
color" - so even in a "confused" = mixed result you don't get actual
color but the color control characters are printed to the screen
instead?
Anyhow, the first time hearing about this kind of problem, and no idea
where else to look. If you don't have gb_COLOR set, and also not
MSYSTEM, then there should be no color to begin with. You can try to
delete the gb_COLOR=$(true) line from solenv/gbuild/Output.mk to make
sure it isn't set by the build itself. (or you can try make gb_COLOR=1
to see whether that makes a difference)

ciao
Christian