Trouble with new lo-build

[Christian Lohmaier]

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