Hi Christian,
it does not work for me.
There was a missing bracket. So I have used
sh -c "cd $(shell cygpath -ml $(BUILDDIR)); $(if $(MSYSTEM),$(WSL)
)$(SRCDIR)/autogen.sh"
Then after making the suggested changes, I run autogen.sh.
After that I see again the changed Makefile files and the bogus
include/include file.
My autogen.sh is
c:/BuildLO4/core/autogen.sh \
--with-external-tar=c:/BuildLO4/externalsrc \
--with-junit=c:/cygwin64/junit/junit-4.10.jar \
--with-ant-home=c:/cygwin64/ant/apache-ant-1.9.5 \
--disable-ccache \
--enable-pch \
--with-visual-studio=2022 \
--enable-dbgutil \
--enable-werror \
--enable-odk \
--disable-cve-tests \
--disable-online-update \
--without-fonts \
--with-jdk-home=c:/BuildLOAdds/jdk \
--enable-python=fully-internal \
PKG_CONFIG=C:/BuildLOAdds/pkg/pkgconf-2.4.3.exe
What information can help you to determine what goes wrong for my build?
Kind regards,
Regina
Christian Lohmaier schrieb am 03.07.2025 um 14:33:
Hi Regina,
On Mon, Jun 30, 2025 at 9:37 PM Regina Henschel <rb.hensc...@t-online.de> wrote:
Christian Lohmaier schrieb am 30.06.2025 um 13:26:
On Mon, Jun 30, 2025 at 12:46 PM Regina Henschel
<rb.hensc...@t-online.de> wrote:
but the next clean build again fails to build skia :(
Hmm. If you didn't say you already started with a fresh clone, I would
have suspected https://gerrit.libreoffice.org/c/core/+/180511 to be
missing/the cause of the problem.
At least that would match the works the first time, but not subsequent
times (after rerunning of autogen.sh is triggered by make and not
manually) >
So please double-check the status of the <module>/Makefile files in
the checkout. If there's confusion about builddir vs srcdir because of
short forms of paths being different than what was used when running
the initial configure, autogen.sh would replace the makefiles in the
srcdir (while it is only supposed to create copies in a separate
builddir)
All Makefile files are altered. For example for folder 'filter':
[…]
That matches the symptoms of mistreating a build in the
source-directory as a build in a separate directory.
So apparently it is not wsl-specifc (anymore?)...
The fix is only addressing the wsl-as-helper case, since at least my
version of cygwin was unaffected, cygwin-perl's realpath would have
rewritten a shortened path to the long form – but maybe that
assumption is wrong and it needs the same fix.
Can you sent me the needed changes, so that I can test it?
It is the fix in https://gerrit.libreoffice.org/c/core/+/180511 basically.
To fix the current situation: reset the makefiles to their initial state:
git checkout -- */Makefile external/*/Makefile
remove the bogus double-include link
rm include/include
git status should not show any touched Makefiles anymore
Then to fix the problem from reappearing: change Makefile.in to have a line
$(BUILDDIR)/config_host.mk : SRCDIR:=/$(shell cygpath -ml $(SRCDIR))
above the ifneq ($(MSYSTEM),) line and change
sh -c "$(if $(MSYSTEM),cd $(shell cygpath -ml $(BUILDDIR)); $(WSL)
)$(SRCDIR)/autogen.sh"
to
sh -c "cd $(shell cygpath -ml $(BUILDDIR)); $(if $(MSYSTEM,$(WSL)
)$(SRCDIR)/autogen.sh"
i.e. move the $(if $(MSYSTEM,) wrapper behind the cd / to only contain
the $(WSL) prefix.
manually run autogen.sh again, since otherwise the old rule from the
generated Makefile would be run and recreate the messup.
The fix is to use the long form of SRCDIR and the long form of
BUILDDIR, so that if autogen.sh compares them they will
match/autogen.sh will recognize they are the same directory.
Since the Makefile at that point doesn't know about any OS or other
variables from config_host.mk the proper fix is probably to move the
path-normalization to autogen.sh
anyhow to trigger the failure prior to fixing and verifying that the fix worked:
touch autogen.input
make fetch
→ that will trigger the rerun of autogen.sh by the makefile without
spending time trying to build something/the make fetch should finish
quickly in any case.
then check whether the Makefiles have been modifier/whether there's
the double include-link.
ciao
Christian
