I see code review comments like “main branch of core repo is not used for anything. Please port this patch to main branch of online repo and abandon here.” from Andras. I’m confused.
I do not want to work on Collabora online, but to the classic desktop version (the version similar to LibreOffice). I have uploaded my current patch proposal https://gerrit.collaboraoffice.com/c/core/+/3807 by using ./cogerrit submit main .
Is that correct? If not, what do I have to do?
Hi @Regina
There is a nice introduction post from Pedro that explains the new repository setup:
Basically, core is no longer developed as a separate project in the way it used to be. The code now lives under the online repository, and the core is now subtree name engine inside online repo shared with the desktop and online.
I hope that forum post helps clarify the new setup and where patches should be submitted.
Thanks,
Darshan
Latest Collabora Office Classic is built from distro/collabora/coc-26.04.
Command should be `./cogerrit submit coc-26.04`.
That does not work. Message: branch coc-26.04 not found.
What does git branch say? And after `git fetch origin`?
Maybe it is `./cogerrit submit distro/collabora/coc-26.04` sorry I did not try.
From ssh://gerrit.collaboraoffice.com:29418/core
I have started now with a new clone into a new folder git clone ssh://regina-henschel@gerrit.collaboraoffice.com:29418/online I’ve got the files.
And with that a git fetch origin has From ssh://gerrit.collaboraoffice.com:29418/online
But building does not work: I have added an autogen.input file and then $ wsl ./autogen.sh returns Result: All went OK, please run ./configure (with the appropriate parameters) now.
But $ wsl ./configure returns error: header Poco/Net/WebSocket.h not found, perhaps you want to use --with-poco-includes There seems to be something missing or what parameters are needed for configure? How to fix that?
Main issue here is which branch to choose.
`distro/collabora/coc-26.04` mentioned above is the one Classic is built from, and that needs cloning of https://gerrit.collaboraoffice.com/core. But latest Smart Art patches may not be there.
To get those, you may clone gerrit.collaboraoffice.com/onlineand cd into and build only engine inside with GUI so that is runs visible. Building engine is with the same parameters as core or LibreOffice. No build of online would be needed.
In that case, patches still need to be ported to coc-26.04 to be seen in Classic.
Maybe we should think over this.
hi @Regina this will help to solve the POCO error: Build Collabora Office for Linux | Collabora Office - Community Page
Thank you. After building POCO it is now found by configure.
But the next problem arises: Configure does not find node. I’ve installed it for Ubuntu and in the Ubuntu terminal a node -v results v24.16.0. But with wsl ./configure in Git Bash I get the error configure: error: node required to build cool, but not installed
In the meantime, I have installed node in Windows as well. Git Bash now returns /c/Program Files/nodejs/node on which node. And a node -v returns v24.16.0. But wsl ./configure still has checking for node… noconfigure: error: node required to build cool, but not installed
What to do? I only want to build the desktop version.
Hi @Regina
Can you check whether WSL itself can see Node?
wsl which node
wsl node -v
If those work, then Node is available in WSL and the problem is likely elsewhere.
Also, are you building the engine repository or the Online (cool) repository? The error mentions COOL, which suggests the Online build system. For a desktop/core build, Node.js should generally not be the blocker, so it would be helpful to see:
pwd
git remote -v
from the directory where you’re running ./configure.
Thanks
Darshan
No, it doesn’t see Node.$ wsl which node has an empty return and $ wsl node -v returns /bin/bash: line 1: node: command not found
But a $ which node returns /c/Program Files/nodejs/node and $ node -v returns v24.16.0.
Oh, I didn’t know, that I need to go into folder engine to get a desktop build. I’ll try that. At least wsl ./autogen.sh works now (without POCO) and make starts. But stops with errors:
C:colwsl7\online\engine\workdir\UnpackedTarball\boost\boost\optional\detail\union_optional.hpp(600) : error C2220: the following warning is treated as an error
C:colwsl7\online\engine\workdir\UnpackedTarball\boost\boost\optional\detail\union_optional.hpp(600) : warning C4702: unreachable code
make[1]: *** [C:/colwsl7/online/engine/solenv/gbuild/LinkTarget.mk:338: C:/colwsl7/online/engine/workdir/CxxObject/svx/source/diagram/datamodel_svx.o] Error 2
And more problems: After update with ./g pull -r in online, next time wsl ./autogen.sh inside folder engine fails with:
checking Visual C++… ./configure: 13566: ./configure.lineno: vswhere+=\Microsoft Visual Studio\Installer\vswhere.exe: not found
./configure: 1: ./configure.lineno: /mnt/c/PROGRA~2: Permission denied
./configure: 1: ./configure.lineno: /mnt/c/PROGRA~2: Permission denied
checking VC++ Build Tools and similar… ./configure: 1: ./configure.lineno: /mnt/c/PROGRA~2: Permission denied
configure: error: no Visual Studio 2022 installation found
I still get no build for collabora office classic and need help.
I have installed Visual Studio 2026 in the meantime. But I still get the above mentioned failure. I can run vswhere in the Git Bash as vswhere and as wsl vswhere.exe and it lists the values for VS2026.
If I comment out the lines #216 to #220 in autogen.sh in folder engine, it find Visual Studio. That part didn’t exist in the autogen.sh that was used for the old core repository.
But doing that does not solve the build problem. It then stops with error
checking for clang-cl… ./configure: line 42158: cygpath: command not found
./configure: line 42160: cygpath: command not found
no
checking the dependency generation prefix (clang.exe -showIncludes)… configure: error: cannot determine the -showIncludes prefix
Error running configure at ./autogen.sh line 344.
My autogen.input is
--host=x86_64-pc-cygwin
–disable-ccache
–with-visual-studio=2026
–enable-python=fully-internal
–without-lxml
–with-external-tar=c:/colwsl7/external
–with-strawberry-perl-portable=c:/bloadds/spp
–with-ant-home=c:/bloadds/apache-ant-1.10.15
–with-junit=c:/bloadds/junit-4.10.jar
–with-jdk-home=c:/bloadds/jdk
–enable-dbgutil
–enable-werror
–disable-cve-tests
–without-fonts
PKG_CONFIG=/mnt/c/bloadds/pkg/pkgconf-2.4.3.exe
What do I need to do? Do you was successful on building engine on Windows 11?
Hi @Regina
Thanks for your patience working through this - the Windows setup has a couple of sharp edges. Both errors come from the same place, so two quick fixes should clear them:
Run from Cygwin bash. cygpath: command not found means the shell isn’t 64-bit Cygwin. The native build has to be launched from the Cygwin terminal (Git Bash and MSYS2 won’t work, as they don’t ship cygpath). Could you also restore the vswhere lines you commented out in autogen.sh? They’re what locates Visual Studio, and removing them is what leads to the -showIncludes error.
Tell configure about VS 2026. By default it only looks for Visual Studio 2022, so a 2026-only machine isn’t found. The code does support 2026, you just need to ask for it. Add this to autogen.input:
–with-visual-studio=2026
Once you’re in Cygwin and VS is detected, the -showIncludes check passes on its own - it was just a knock-on effect of the compiler not being found.
One honest note: VS 2026 support is brand new, so if it keeps fighting you, VS 2022 is the well-tested baseline and the smoother route.
I haven’t built on Windows 11 myself, so this is from reading the build scripts - the LibreOffice “BuildingOnWindows” wiki page is the fullest reference, and it applies directly since the engine shares core’s build system.
Thanks,
Darshan
I’m not using Cygwin but WSL2. That has worked with the old core and works for LibreOffice, thus I don’t understand why it doesn’t work now with engine.
I use already --with-visual-studio=2026, see posted autogen.input.
I mean the lines
# Favor noticeably faster dash, when available if ($system eq 'Linux' and not defined $ENV{CONFIG_SHELL}) { chomp(my $dash = `command -v dash 2>/dev/null`); $ENV{CONFIG_SHELL} = $dash if $dash; }
How are these lines connected to vswhere? If I comment them out Visual Studio is found, with them it is not found.
I have installed VS 2026 because that is said on Build Collabora Office for Windows | Collabora Office - Community Page
I have tried with VS 2022 as well, and it fails with the same problem:
checking Visual C++... ./configure: 13521: ./configure.lineno: vswhere+=\Microsoft Visual Studio\Installer\vswhere.exe: not found
./configure: 1: ./configure.lineno: /mnt/c/PROGRA~2: Permission denied
./configure: 1: ./configure.lineno: /mnt/c/PROGRA~2: Permission denied
checking VC++ Build Tools and similar... ./configure: 1: ./configure.lineno: /mnt/c/PROGRA~2: Permission denied
configure: error: no Visual Studio 2022 installation found
Error running configure at ./autogen.sh line 344.
I’m at a loss.
Hi @Regina,
These instructions are for the new Collabora Office, not for Collabora Office Classic. 
Hi @Regina
Let me try to simplfy here the build for collabora classic
Fix is simpler than it looks. In WSL2 you have two options: a plain Linux build (gcc, what you did for old core and LibreOffice), or a cross-build to native Windows binaries (Visual Studio toolchain). Every error you hit - vswhere, “Visual Studio 2026”, cygpath, -showIncludes - comes from the Windows toolchain.
The engine is the same core build system, so a plain Linux build works exactly as it did for old core.
To get back to the familiar Linux build:
Building on Linux: Making sure you're not a bot!
--enable-debug
cd engine
./autogen.sh
make
That’s the same flow you know from old core.
I hope this will help to make things easy here 
checking Visual C++… ./configure: 13521: ./configure.lineno:
vswhere+=\Microsoft Visual Studio\Installer\vswhere.exe: not found
I don’t typically build under windows, and windows can be tricky with
all the different wrappers and unix-alike tool provider possibilities,
path hackery and now wsl.
I think there’s two problems.
syntax problem. That build optimization effort is guarded behind
“Linux” and it passed our windows ci. The idea was that if it passed
windows ci then dash either worked or it wasn’t present. That doesn’t
actually seem to be the case, so lets just do:
https://gerrit.collaboraoffice.com/c/online/+/4299 to drop that
explicitly for wsl for now. So that’s the same outcome as your local
“comment it out”. So keep that commented out or apply the above.
B: Then I think the next issue is the “cygpath not found”. So before
you run any ./autogen.sh or ./configure what is the output of
$ command -v cygpath
or
$ which cygpath
and in what shell are you running it?
I think the assumption built into windows/coda/README.md and
its --host=x86_64-pc-cygwin argument is that autogen/configure is
launched from a git-bash shell. I do have that installed on a Windows
env and if I run “git bash” (from the windows launcher menu thing) and
do “which cygpath” I get /usr/bin/cygpath
I think there is yet another alternative window configure route where
the cygpath is “Emulation of Cygwin’s cygpath command for WSL” as a
function within configure.ac that kicks in only without the use of
–host=x86_64-pc-cygwin. I have no idea if that route was the one you
had in the pre engine-merge build or if there was another cygpath
somewhere in your path.
I have just learned in the ESC meeting, that the current VS version 18.7. produces the above mentionend error: cannot determine the -showIncludes prefix. Thus I will try what I get, when I go back to version 18.6. I’ll answer your other questions later.
In the meantime, I have tried to use Cygwin instead of WSL2. With Cygwin and Visual Studio 2022, configure works, but the build itself breaks in online/engine/cli_ure/source/native/native_bootstrap.cxx(288).
I’ll report back after my next tries.
I get that too.
I build in Git Bash. However, autogen is called as wsl ./autogen.sh.
I’ve gone that way. I have reverted Visual Studio to version 18.6.2. Configure works then and I can run make. It loads the externals and starts building. But then it fails with the same error as I have got in my Cygwin try. The error message is:
C:/colwsl7/online/engine/cli_ure/source/native/native_bootstrap.cxx(288): error C2039: 'bootstrap': is not a member of 'cppu'
C:\colwsl7\online\engine\include\cppuhelper/bootstrap.hxx(34): note: see declaration of 'cppu'
C:/colwsl7/online/engine/cli_ure/source/native/native_bootstrap.cxx(288): error C2440: 'initializing': cannot convert from 'unoidl::com::sun::star::uno::XComponentContext ^' to 'com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext>'
C:/colwsl7/online/engine/cli_ure/source/native/native_bootstrap.cxx(288): note: No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
Perhaps someone else can try a Windows build of engine using WSL2?
What has changed from core to engine?
For example, in include/cppuhelper/bootstrap.hxx, I see that the lines
CPPUHELPER_DLLPUBLIC css::uno::Reference< css::uno::XComponentContext >
SAL_CALL bootstrap();
were removed.
At which point you are probably into differences between what is in
distro-configs/CODAWindows.conf
vs not using “–with-distro=CODAWindows”
so my guess is that adding (at least) --disable-cli to your
configuration line would get past that unbuilt-in-default-ci module.
I imagine the direction will be to make the various explicit
CODAWindows.conf options that skip building certain parts into eventual
removal of those parts