Розробка/Збірка на Windows

    From The Document Foundation Wiki
    This page is a translated version of the page Development/BuildingOnWindows and the translation is 58% complete.
    Outdated translations are marked like this.

    Вибір хоста / цільової системи

    Оскільки 114ed73a7ba56e013e6d7f886798915fb20c0946 (для отримання додаткової інформації: https://lists.freedesktop.org/archives/libreoffice/2020-September/085869.html), що в основному перекладається як починаючи з LibreOffice 7.1, старий перемикач конфігурації --enable-64-bit було відкинуто. Щоб явно вибрати архітектуру, вам слід вказати правильний триплет configure host:

    • --host=i686-pc-cygwin: ціль 32-bit Intel / AMD host
    • --host=x86_64-pc-cygwin: ціль 64-bit AMD / Intel host
    • --host=aarch64-pc-cygwin: ціль 64-bit ARM host (WIP, але має працювати загалом - див. баг tdf#137143)

    Для всіх версій до LibreOffice 7.1 збірка за замовчуванням завжди є 32-розрядною у Windows, і ви повинні явно викликати autogen.sh/configure з параметром --enable-64-bit, щоб отримати 64-розрядну збірку.

    В іншому випадку ваша збірка і хост-система будуть однаковими, визначеними скриптом конфігурації, що, ймовірно, вам і потрібно у будь-якому випадку.

    Залежно від вашого рішення, ви повинні встановити версію Java, яка відповідає цільовій архітектурі та розрядності.

    Приклад для крос-компіляції Windows Arm64 з Java

    • --host=aarch64-pc-cygwin або --with-distro=LibreOfficeWinArm64
    • --with-build-platform-configure-options=--with-jdk-home=C:/PROGRA~1/Java/JDK-17~1.1
    • --with-jdk-home=/cygdrive/c/lode/jdk-17-ea+25-windows-aarch64

    Перший - це встановлена Oracle x86_64 Java, 2-й - розпакований попередній реліз Windows Arm64 OpenJDK Java.

    Побудувати залежності

    Перш ніж розпочати розробку LibreOffice на Windows, вам потрібно виконати ці інструкції для налаштування середовища збірки. Також прочитайте наші загальні підказки зі складання.

    Встановлення Visual Studio

    Вам потрібен компілятор/пакет розробника Microsoft Visual Studio, який можна завантажити звідси: https://visualstudio.microsoft.com/downloads/

    Існує безкоштовна версія Community Edition, яка включає в себе все необхідне для створення всіх функцій LibreOffice: https://visualstudio.microsoft.com/vs/community/

    Поточний майстер (починаючи з LibreOffice 7.0) вимагає Visual Studio 2019 (принаймні v16.5) (або еквівалентного інструментарію збірки Visual Studio).

    Починаючи з VS 2017, доступний окремий пакет Build Tools, який містить компілятори та більшість інструментальних засобів і бібліотек без встановлення IDE Visual Studio: https://visualstudio.microsoft.com/downloads/#build-tools-for-visual-studio-2019. Note that this option excludes convenient/efficient debugging experience.

    Для старіших версій LibreOffice потрібні наступні версії Visual Studio:

    • LibreOffice 4.4 потребує Visual Studio 2012
    • LibreOffice 5.0 потребує Visual Studio 2013
    • LibreOffice 5.4 потребує Visual Studio 2015
    • LibreOffice 6.2 потребує Visual Studio 2017
    • LibreOffice 6.3 можна зібрати за допомогою Visual Studio 2017 або 2019
    • LibreOffice 7.0 потребує Visual Studio 2019
    • LibreOffice 7.3 можна зібрати за допомогою Visual Studio 2019 або 2022

    Visual Studio 2019 може опціонально встановлювати компілятори 2017 та 2015 років (VS 2015 / 2017 C++ Buildtools). Єдине, чого не вистачає, це старих пакунків C++ Redistributable MSM, тому старіші скрипти configure.ac потребують невеликого виправлення для збирання пакунків MSI.

    Старіші версії Visual Studio доступні за посиланням https://visualstudio.microsoft.com/vs/older-downloads/.

    Visual Studio (та Visual Studio Build Tools) 2019 принаймні v16.5 працює на поточному майстрі. Виберіть Десктопна розробка з C++ і перевірте, щоб усі наведені нижче компоненти були вибрані окремо:

    • MSVC v14x - VS 20xx C++ x64/x86 build tools (Latest)
    • C++ core desktop features
    • Windows 10 (or 11) SDK (10.0.xxxxx.x), with SDK version > 10.0.20*
    • Windows Universal C Runtime
    • C++ ATL for v14x build tools (x86 & x64)
    • .NET Framework 4.x SDK (.NET Framework 5.x SDK і пізніших версій наразі не підтримуються. Вони не реєструють свою інформацію в реєстрі, не мають csc.exe і використовують команду dotnet з csc.dll замість неї для компіляції.)
    • C++ 20xx Redistributable MSMs (потрібен лише для створення інсталятора MSI)
    • C++ Clang Compiler for Windows (x.x.x)

    Якщо ви хочете виконати крос-збірку для ARM64, вам потрібно вибрати наступні додаткові компоненти:

    • MSVC v142 - VS 20xx C++ ARM64 build tools (v14.2x)
    • C++ ATL for v142 build tools (ARM64)

    Ви можете вибрати ці опції в інсталяторі VS.

    Перерозподілювані MSM (потрібні лише для створення інсталятора MSI) не є частиною вибору робочого навантаження у 2019 році і пізніше, але їх потрібно вибирати з вибору окремих компонентів. Детальніше див. у коментарях до запитань спільноти розробників VS Де MergeModules для 14.20.27404.0 та 14.20.27508? та Deprecation of CRT redist MSMs?.

    Note pin.svg

    Note:
    Інструменти командного рядка Visual Studio використовують системну кодову сторінку OEM для виведення повідомлень у консоль, якщо відповідну мову інтерфейсу встановлено під час інсталяції Visual Studio. Стандартна кодова сторінка у Windows залежить від системної локалі, визначеної за допомогою параметра "Мова для програм, що не підтримують Юнікод" у аплеті intl.cpl (опис параметра), і часто є несумісною з кодуванням, встановленим у оболонці cygwin (зазвичай UTF-8). Це призводить до спотворення результатів роботи інструментів у журналі збирання. Щоб уникнути цієї проблеми, переконайтеся, що під час встановлення Visual Studio ви встановлюєте лише англійську версію інтерфейсу, щоб уникнути цієї проблеми.

    Встановлення Java

    Незалежно від того, яку версію Visual Studio ви використовуєте, вам потрібно

    • Java Development Kit (JDK) версії 17 або новішої (див. [1]). Переконайтеся, що ви отримали 32-розрядний SDK, якщо збираєте 32-розрядну Windows, і 64-розрядний SDK, якщо збираєте 64-розрядну Windows. Завантажте Temurin з adoptium.net, JDK з oracle.com (для завантаження Oracle потрібно увійти до системи) або OpenJDK з microsoft.com (збірка OpenJDK від Microsoft не вимагає входу).

    Зверніть увагу, що Oracle JDK є лише 64-розрядним.

    Зверніть увагу, що встановлення Temurin не буде здійснено автоматично: для цього потрібно вручну увімкнути опцію "Ключі реєстру JavaSoft (Oracle)".

    У вашому файлі autogen.input вкажіть шлях таким чином: --with-jdk-home=C:/Program Files/...

    Якщо ви виконуєте перехресну компіляцію на 64-розрядний ARM, вам потрібно вказати різні JDK для інструментів збірки та цільового хоста. Хоча інструменти збірки зрештою визначать правильний JDK, вам слід використати --with-jdk-home=<директорія JDK для ARM64, щоб вказати JDK на хості. Ви можете перевизначити збірку JDK за допомогою --with-build-platform-configure-options=--with-jdk-home=<директорія JDK для x64>.

    Встановлення Cygwin та інших залежностей

    Note pin.svg

    Note:
    Найпростіший спосіб виконати наведені нижче дії - використати LODE , який автоматизує все необхідне, окрім встановлення Visual Studio та Java.

    Якщо ви хочете зробити це складним шляхом, продовжуйте читати.

    Встановлення Cygwin

    У Windows ви повинні встановити Cygwin з www.cygwin.com. Остання версія Cygwin має працювати нормально. Версію можна перевірити за допомогою команди uname -a.

    Найпростіший спосіб зробити це - завантажити Cygwin setup-x86.exe (32-розрядний) або setup-x86_64.exe (64-розрядний).

    • Бажано використовувати 64-розрядний Cygwin, якщо це можливо, тому що він менш схильний до проблем з fork() (див. Cygwin FAQ для отримання детальної інформації).

    У цій інструкції для прикладу наведено 64-бітну версію: Запустіть cmd і перейдіть до теки завантаження (якщо у вас виникли проблеми з навігацією, ви також можете перетягнути setup-x86_64.exe з файлового провідника у вікно cmd), скопіюйте і вставте команду нижче, щоб запустити setup-x86_64.exe зі списком необхідних пакунків, які попередньо вибрано.

      setup-x86_64.exe -P autoconf -P automake -P bison -P cabextract -P doxygen -P flex -P gcc-g++ ^
                    -P gettext-devel -P git -P gnupg -P gperf -P make -P mintty ^
                    -P nasm -P openssh -P openssl -P patch -P perl -P python -P python3 ^
                    -P pkg-config -P rsync -P unzip -P vim -P wget -P zip -P perl-Archive-Zip ^
                    -P perl-Font-TTF -P perl-IO-String
    

    Це запустить графічний інтерфейс і вимагатиме від вас вручну вибрати шляхи встановлення тощо, але пакунки, передані через командний рядок, вже вибрано заздалегідь, тож вам потрібно лише прийняти вибір.

    NOTE: шлях до інсталяції Cygwin не повинен містити не-ASCII літер, щоб уникнути проблем з файлом autogen.sh/configure (якщо він містить, перемістіть папку з інсталяцією Cygwin на нове місце і оновіть ярлики Windows та пункти меню "Пуск").

    Крім того, запустіть утиліту setup-x86.exe або setup-x86_64.exe, перемкніть режим перегляду пакунків на "Повний", натискаючи кнопку "Перегляд", доки поруч не з'явиться напис "Повний", а потім вручну виберіть пакунки, перелічені у наведеній вище команді, для встановлення.

    Якщо ви оновили Cygwin, можливо, вам доведеться виконати команду rebaseall (не потрібна, якщо ви інсталюєте Cygwin уперше):

    Закрийте всі консолі Cygwin, запустіть c:\cygwin\bin\dash.exe і у терміналі запустіть /bin/rebaseall.

    Інші залежності

    Після встановлення Cygwin відкрийте командний рядок Cygwin, натиснувши на його іконку Cygwin64 Terminal на робочому столі, і виконайте наступні кроки:

    Встановлення GNU Make

    Для збирання LibreOffice доступна (і необхідна) збірка GNU Make 4.0+ для Win32.

    Найпростіше розмістити його у /opt/lo/bin, де configure автоматично знайде його; ви також можете використати інше місце і встановити змінну MAKE. Або додайте /opt/lo/bin до PATH, або, як варіант, коли ви збираєте LibreOffice, завжди викликайте "make" з абсолютним шляхом /opt/lo/bin/make (або куди ви його поклали). LibreOffice не може і не повинен використовувати /usr/bin/make від Cygwin.

    mkdir -p /opt/lo/bin
    cd /opt/lo/bin
    wget https://dev-www.libreoffice.org/bin/cygwin/make-4.2.1-msvc.exe
    cp make-4.2.1-msvc.exe make
    chmod +x make
    


    Встановлення ant та junit

    Ви можете витягти їх звідки завгодно, їх не потрібно встановлювати. Якщо ви не хочете використовувати Junit, його можна вимкнути за допомогою --without-junit у команді autogen.sh пізніше.

    mkdir -p c:/sources
    cd c:/sources
    wget https://archive.apache.org/dist/ant/binaries/apache-ant-1.9.5-bin.tar.bz2
    tar -xjvf apache-ant-1.9.5-bin.tar.bz2
    wget http://downloads.sourceforge.net/project/junit/junit/4.10/junit-4.10.jar
    

    Also works with the combination of junit 4.13,hamcrest 2.2 and Apache Ant 1.10.12

    Клонування сховищ вихідного коду LibreOffice

    NOTE: джерела мають бути у відносно короткому шляху, щоб уникнути перевищення ліміту файлів/шляхів, а шлях призначення не повинен містити пробілів.

    cd c:/sources
    git clone https://gerrit.libreoffice.org/core libo-core
    
    За бажанням створіть каталог збірки

    Ви можете збирати LibreOffice у іншому каталозі, ніж каталог перевірки. Це допомагає зберегти дерево вихідних текстів чистим і полегшує збірку кількох версій.

    Якщо ви хочете зібрати в окремий каталог, скажімо /cygdrive/c/build, введіть ці команди:

    mkdir c:/build
    cd c:/build
    

    Інакше змініть каталог на теку /cygdrive/c/sources/libo-core:

    cd c:/sources/libo-core
    
    Налаштуйте та створіть код

    Тепер запустіть autogen.sh, щоб налаштувати збірку:

    c:/sources/libo-core/autogen.sh \
                 --with-external-tar=c:/sources/lo-externalsrc \
                 --with-junit=c:/sources/junit-4.10.jar \
                 --with-ant-home=c:/sources/apache-ant-1.9.5 \
                 --enable-pch --disable-ccache \
                 [додаткові перемикачі, якщо ви знаєте, що робите :-) ...]
    

    Зауважте, що якщо ви встановили ccache з середовища Cygwin, рекомендується вимкнути його за допомогою --disable-ccache, як у наведеній вище команді, оскільки він не забезпечує помітного покращення швидкості. З іншого боку, ви можете використовувати VS збірки кешу, які дають хороший приріст швидкості.

    Якщо скрипт autogen.sh скаржиться, що не може знайти деякі заголовні файли, можливо, він не може знайти ваш Windows SDK або знайшов пошкоджений. Це може статися, якщо на вашому комп'ютері встановлено декілька версій Visual Studio, особливо якщо ви встановили бета-версію, і навіть якщо ви її видалили. У цьому випадку ви можете скористатися параметром --with-windows-sdk=7.1A, можливо, замінивши 7.1A на іншу версію SDK, щоб вибрати конкретну неушкоджену версію.

    Крім того, configure.ac, який використовується autoconf, передає cl.exe -showIncludes, щоб дізнатися, який префікс використовується cl.exe для кожного включеного заголовка. Під час запуску команда може не знайти vcruntime.h, який використовується stdlib.h. Користувачі Visual Studio зазвичай використовують консоль розробника при виконанні команди cl, де викликається файл vcvarsall.bat для встановлення необхідних змінних оточення, які можуть бути відсутніми при використанні autoconf.

    Збережіть копію останніх використаних параметрів у файлі autogen.input. Вона не буде перевизначена autogen.sh при використанні інших параметрів. Якщо autogen.sh буде викликано повторно без параметрів, він отримає вхідні дані з autogen.input, якщо вони є.

    На цьому етапі ви можете розглянути додаткові опції для передачі автогену за допомогою

    $ ./autogen.sh --help

    Наприклад, розглянемо можливість додавання Опція налагодження. Зміна деяких з цих параметрів вимагатиме повної перезбірки: наприклад, додавання --enable-dbgutil. Оскільки наведена нижче команда make потребує багато часу для першого запуску, ви, ймовірно, захочете заощадити час, вказавши потрібні вам параметри залежно від кінцевої мети вашої збірки. У разі сумнівів, можливо, варто звернутися за порадою до #libreoffice-dev.

    Прочитайте підсумковий висновок команди autogen.sh. Якщо вона не повідомила про жодні помилки або відповідні попередження, то все, що вам залишилося зробити, це запустити потрібну версію make для збирання LibreOffice. Перш ніж це зробити, переконайтеся, що ваше антивірусне програмне забезпечення не спричиняє жодних проблем.

    /opt/lo/bin/make gb_COLOR=1  # gb_COLOR=1 вмикає кольоровий вивід
    


    Запуск LibreOffice

    Коли збірка завершиться без помилок, ви можете запустити свіжу збірку LibreOffice за допомогою

    instdir/program/soffice.exe
    


    Інтеграція проектів Microsoft Visual Studio

    Система збирання LibreOffice може генерувати файли проектів для деяких середовищ розробки, зокрема - завдяки чудовій роботі Honza Havlíček - для Microsoft Visual Studio: (зауважте, що це не дає змоги виконати повне збирання, тому вам все одно доведеться використовувати Cygwin для виконання повного збирання).

    Please accept this video. By accepting you will be accessing content from YouTube, a service provided by an external third party.

    YouTube privacy policy

    Створення файлу проекту для Visual Studio

    Скрипт інтеграції з IDE написано мовою python3, яка не встановлена за замовчуванням (за допомогою методу lode), будь ласка, встановіть її у cygwin перед виконанням команди make. Після успішного завершення збірки LibreOffice виконайте наступну команду, щоб згенерувати проект Visual Studio:

    $ /opt/lo/bin/make vs-ide-integration
    

    Якщо генерація пройшла успішно, отриманий файл рішення LibreOffice.sln буде розміщено у кореневому каталозі збірки і його можна буде відкрити за допомогою Microsoft Visual Studio.

    Дивіться Розробка / IDE / Microsoft Visual Studio для отримання детальної інформації, зокрема про команди, що використовуються у старих гілках та відомі проблеми.

    Чому MSVC?

    Часто задають питання, зазвичай від пуристів вільного програмного забезпечення, чому ми використовуємо пропрієтарний компілятор, а не вільний (наприклад, gcc).

    • Зворотна сумісність ABI для скомпільованих розширень. Існує певний опір порушенню цієї сумісності.
    • Наразі MSVC створює швидші та менші за розміром двійкові файли.
    • У коді є деякі функції, які не компілюються за допомогою MinGW. Вони використовують API, для яких MinGW не надає заголовків тощо.
    • Існують відкриті питання щодо того, як запускати модульні тести у середовищі крос-компіляції MinGW.
    • Відкритими залишаються питання щодо того, наскільки добре gdb працює під Windows; налагоджувач C++ MSVC справді дуже хороший.

    Опції autogen

    Відомо, що для створення робочої збірки потрібно вказати у файлі autogen.input щось на кшталт наведеного нижче:

    --disable-odk
    --with-junit=c:/sources/junit-4.10.jar
    --with-ant-home=c:/sources/apache-ant-1.9.5
    

    Звісно, змініть інформацію за ='s відповідно до ваших потреб; встановіть шляхи до того, що ви використовували під час встановлення різних передумов.

    Також потрібно вказати шлях для ant за допомогою --with-ant-home=<cygwin path of ant>.

    64-бітна збірка Visual Studio

    Перенос для 64-розрядної Windows працює у режимі master з усіма підтримуваними компіляторами. Щоб його зібрати, скористайтеся прапором --enable-64-bit для налаштування у версіях, старіших за LibreOffice 7.1.

    Зауваження щодо старих та не стандартних компіляторів MS

    Переключення на компілятор не за замовчуванням

    Вкажіть, яку версію Visual Studio використовувати, якщо їх встановлено декілька.

    Залежно від гілки можуть підтримуватися різні версії, наприклад, 2015, 2017 для libreoffice-6-1, і зазвичай за замовчуванням буде вибрано найстарішу з підтримуваних версій.

    --with-visual-studio=2019
    

    If you want to use Visual Studio 2022, you have to say it explicitly:

    --with-visual-studio=2022
    


    Запуск Glade на Windows

    Для редагування діалогових вікон (.ui файлів) вам потрібен Glade. Існує стара версія для Windows, але вона не підтримує всі властивості, які потрібні для діалогів LibreOffice.

    Отже, вам потрібно встановити Glade у Cygwin:

    • Встановіть Glade у Cygwin, запустивши інсталятор Cygwin, а потім встановіть наступні пакунки:
    xorg-server, glade, dbus
    • You may have to invoke:
     dbus-uuidgen > /etc/machine-id
    • Додайте це до вашого .bashrc:
    export GLADE_CATALOG_SEARCH_PATH=<path_to_core>/instdir/share/glade
    • Відкрийте консоль Cygwin і запустіть:
    X -multiwindow
    • Відкрийте іншу консоль Cygwin і запустіть:
    DISPLAY=:0.0 glade

    Це все, тепер ви повинні запустити Glade ≥ 3.18

    Glade 3.20.3 на Windows 10, редагування svx/uiconfig/ui/addmodeldialog.ui

    Відомі проблеми

    Cygwin та git

    Основна проблема полягає в тому, що cygwin-git працює дуже повільно.

    Альтернативи такі:

    • Встановіть win-git звідси: https://gitforwindows.org/ (Це встановить "Git-Bash Here" у Провіднику)
    • Використовуйте Windows Subsystem for Linux (WSL) для встановлення дистрибутива Linux (див., наприклад https://www.sitepoint.com/wsl2-windows-terminal/ як встановити дистрибутив і, за бажанням, Windows Terminal)

    Ось випадки, коли використовують один і той самий комп'ютер і репо, і це не є першим дзвінком:

    git status

    git Версія Час [сек]
    cygwin 2.21.0 20
    win 2.22.0 1
    WSL 2.16.0 6

    Git у WSL працює повільніше, ніж git-bash, але він має перевагу в тому, що працює в повному середовищі Linux з усіма іншими інструментами, що надаються дистрибутивом. Не слід змішувати інструменти з Cygwin і WSL (тобто відкривати окремі термінали для Cygwin і для WSL).

    ПРИМІТКА: Поєднання різних git-інструментів не завжди сумісне, при зміні інструменту слід оновити (клонувати) git-сховища.

    Щоб уникнути цієї проблеми, краще налаштувати "autocrlf" перед клонуванням майстра (див. нижче, як налаштувати "autocrlf" на розумне значення).

    Executable permission on files

    It is desirable to use filemode = false in the [core] section of .git/config, to avoid all files having executable permission in cygwin-git. This setting allows Git to ignore the differences between file modes of files on disk and in index, which is useful with cygwin-git, which sees all files on disk as having executable permission (755 instead of typical 644). However, sometimes you need to add a script file with executable permission, and with the mentioned setting, you would need to use an explicit command to set the permission to the added file:

    git update-index --chmod=+x myfile.sh

    Cygwin Shell

    You will use Cygwin Bash Shell for the whole build process. You must install all the build dependencies above before starting the shell to run autogen because autogen needs some environment variables to find the tools.

    If you see an error similar to the following when running autogen.sh

       $'\r': command not found
    

    This means that Windows style newline characters are creating issues with the Cygwin Shell. Unfortunately, the default mode for Git for Windows is automatically changing line endings on file checkout. A good way to solve this is to configure git to clone without changing line ending. To do so, give the following command in Cygwin Shell:

       git config core.autocrlf false
    


    Big List Of Dodgy Apps

    If you get mysterious build breaks, the building is very slow or your systems hang totally, check if you are running an application that interferes with Cygwin. For a list of known offenders, see this point in the Cygwin FAQ.

    BitDefender / other Anti-Virus / security tools breaking the build

    If your build fails with a FileNotFoundError: such as The system cannot find the file specified: '../../../dist/out/bin\\example.exe', there's a good chance your Anti-Virus is quarantining or deleting important files.

    Another potential source of problems is the sample documents (those labeled CVE) that check for known vulnerabilities to ensure they don't reappear again. In the source they are stored encrypted to avoid triggering the warnings, but when the corresponding test is run, the original is created in the temp directory and tools such as BitDefender can flag it.

    If you want to run these tests, disable monitoring of the temporary build-directories <root of repo>\*\pass and C:\cygwin\tmp in your Anti-Virus tool. For Windows 8 and 10 you will need to disable Windows Defender launch - search for and launch 'defender' from the shell.

    You can also use the --disable-cve-tests autogen flag to skip the tests that are known to cause trouble.

    Also note that Anti-Virus tools can slow down your build quite a bit, if you want to build fast you should disable real-time monitoring of the source tree and the temporary files directory C:\cygwin\tmp.

    Norton Antivirus breaking the build

    Norton Antivirus and Symantec Endpoint Protection complain about certain files that the build produces. It finds the following files (in a build without "--enable-dbgutil" )

    Malware: Suspicious.Cloud
    D:\bld\rel\workdir\UnpackedTarball\icu\source\bin\genrb.exe*
    Malware: Suspicious.Cloud.5
    D:\bld\rel\workdir\UnpackedTarball\nss\nss\lib\zlib\out\example.exe*
    D:\bld\rel\workdir\UnpackedTarball\nss\dist\out\bin\example.exe* 
    D:\bld\rel\instdir\program\reg4allmsdoc.dll
    D:\bld\rel\instdir\program\sdqsmsi.dll
    D:\bld\rel\instdir\program\sellangmsi.dll
    

    Files with * are needed for the build - exclude them from the virus scan!

    The following files appear with varying names (????) in a release build, so you cannot exclude them from the scan.

    D:\bld\rel\instdir\program\RCX????.tmp
    D:\bld\rel\instdir\program\RCX????.tmp
    D:\bld\rel\instdir\program\RCX????.tmp
    

    Current workaround: Don't do release builds (unless you are allowed/willing to switch off the virus scanner).

    System PATH causing weird build breakage

    If you experience weird build breakage that no one else seems to experience, check your PATH value and try cleaning it. Note that you need to open a new shell and re-run autogen.sh in order for the new system PATH value to take effect in your build. Some people have experienced a build failure in the shell module due to their system PATH including a path to an older OOo installation that had a DLL of the same name as the one that the build uses.

    Windows Update automatically reboot during compilation

    Sometimes Microsoft Windows reboot during compilation. It happens because Windows Update updates operating system and reboot. To stop windows update from command line, you can enter following command in command box:

    C:> net stop wuauserv
    

    It stops a Windows Update service process.

    Failing PDF signing tests

    On Windows, it can happen, that PDF signing tests are failing:

    [build CUT] xmlsecurity_pdfsigning
    warn:sfx.appl:2956:6324:sfx2/source/appl/app.cxx:193: No DDE-Service possible. Error: 16399
    warn:svl.crypto:2956:6324:svl/source/crypto/cryptosign.cxx:1415: CryptAcquireCertificatePrivateKey failed: Das Zertifikat und der private Schlüssel für die Entschlüsselung wurden nicht gefunden.
    warn:vcl.filter:2956:6324:vcl/source/filter/ipdf/pdfdocument.cxx:846: PDFDocument::Sign: PDFWriter::Sign() failed
    C:/Users/davido/projects/libo/xmlsecurity/qa/unit/pdfsigning/pdfsigning.cxx:174:PDFSigningTest::testPDFAdd assertion failed
    - Expression: aDocument.Sign(aCertificates[0], "test", true)
    

    Solution: Remove expired Own Certificate:

    http://imgur.com/a/NdCxT

    1. Start certmgr
    2. proceed to Own Certificates
    3. Remove expired certificate
    4. Repeat the tests
    5. Done

    Short filenames (8.3 filenames)

    If you get an error like the following one:

    configure: error: converted path "C:/PROG~1/Microsoft SDKs/Windows/v8.1A/bin/NETFX4~1.1TO/" still contains spaces. Short filenames (8.3 filenames) support was disabled on this system?
    Error running configure at ./autogen.sh line 300.
    

    Then ensure 8.3 name creation is enabled. Open the Command Prompt as administrator and run:

    fsutil 8dot3name query c:
    

    Also, check that the conflicting folder (in this case, "Microsoft SDKs") has a corresponding 8.3 filename. For example:

    cd C:\Program Files (x86)\
    dir /x M*
    

    This will print a list of folders beginning with "M" and their associated 8.3 filenames. If "Microsoft SDKs" does not have a short filename, you can rename it to "tmp", then create a new folder "Microsoft SDKs", check that it has a short filename and move the contents of "tmp" to "Microsoft SDKs".

    When choosing a directory in which to install LODE, please use the 8.3 rules. Windows does not correct environment variables, therefore e.g. LODE_HOME will be wrong and will cause problems. Therefore, always clone lode in an 8.3 path such as:

    C:\source\LO\lode
    

    autogen.sh might report that it cannot find mscvc.exe.

    This is caused by the long filename problem as well, but the solution is a bit more work:

    Shift+reset, go to the safe mode, do this:

    fsutil 8dot3name set c: 0
    fsutil file setshortname "Program Files (x86)" PROGS
    fsutil file setshortname "Microsoft Visual Studio 12.0" msvc-12
    fsutil file setshortname "Windows Kits" W~Kits
    

    Correct your PATH variable

    MS Windows Security / Crypto related problems

    There is a document describing various fixes for Windows Security / Crypto related problems in the Windows Server troubleshoot documentation: https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/windows-security-overview. It has a subsection for Permissions, access control, and auditing.

    ALINK : error AL1078: Error signing assembly -- Access is denied

    Fix: the correct permissions for the MachineKey folder are described in https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/default-permissions-machinekeys-folders. A more elaborated description is in https://odetocode.com/blogs/scott/archive/2020/01/12/solving-access-denied-in-crypto-machine-keys.aspx. It's a bit complex to get right, so check twice.

    Alternative workaround: open the Developer Command Prompt for VS as an administrator, and use sn tool to set `AL.EXE` to use the current user key set to sign assemblies instead of using the machine key set:

    sn -m n
    


    This modifies the following registry keys:

    for 64-bit systems:

    HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\StrongName

    for 32-bit systems:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\StrongName

    .NET exception occurred: System.IO.IOException: Access is denied

    You may run into this error message while building the cli_uretypes module:

    [build DEP] LNK:Executable/climaker.exe

    [build LNK] Executable/climaker.exe
    LINK : /LTCG specified but no code generation required; remove /LTCG from the link command line to improve linker performance
    [build CLI] cli_uretypes
    > error: .NET exception occurred: System.IO.IOException: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
      at: System.Reflection.Emit.ModuleBuilder.SavePEFile(RuntimeModule module, String fileName, Int32 entryPoint, Int32 isExe, Boolean isManifestFile)
      at: System.Reflection.Emit.ModuleBuilder.Save(String fileName, Boolean isAssemblyFile, PortableExecutableKinds portableExecutableKind, ImageFileMachine imageFileMachine)
      at: System.Reflection.Emit.AssemblyBuilder.SaveNoLock(String assemblyFileName, PortableExecutableKinds portableExecutableKind, ImageFileMachine imageFileMachine)
      at: System.Reflection.Emit.AssemblyBuilder.Save(String assemblyFileName, PortableExecutableKinds portableExecutableKind, ImageFileMachine imageFileMachine)
      at: ?A0x8a0098b7.sal_main()
    > dying abnormally...make[1]: *** [E:/master/cli_ure/CliUnoApi_cli_uretypes.mk:14: E:/master/instdir/program/cli_uretypes.dll] Error 1
    make: *** [Makefile:123: cli_ure.build] Error 2
    

    To solve this you need to grant (as Administrator)

    Modify
    

    permission for the Users group to the folder

    C:\ProgramData\Microsoft\Crypto
    

    Other known problems

    • Paths that include /opt cause problems with some external modules; it is best to avoid having your source tree in /opt; or use --disable-orcus to overcome this.
    • Asian locale builds sometimes fail due to encoding issues in the source code; in these cases, patches to fix those problems are appreciated. Alternatively, configure Windows for a US locale.

    Using a Windows program as your git editor

    Paths under Cygwin are an endless source of nightmares. This section documents using Notepad++ as your git editor under Cygwin. It assumes you are using the 64-bit version of Notepad++ (adjust the path, if using the 32-bit version).

    Below you will find a wrapper script written by Gene Pavlovsky

    (original gist in GitHub).

    1. Save the script as cygrun.sh into the bin directory in Cygwin's root (so it is in the PATH). When saving the cygrun.sh using Notepad++, do this first to make sure it has Unix line endings: from the "Edit" menu, select "EOL Conversion" -> "UNIX (LF)".
    2. In a Cygwin shell inside the bin directory, give this command to create a symbolic link:
    ln -s cygrun.sh cygrun
    1. Give this command in your home directory:
    git config core.editor "cygrun -w 'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin"

    or alternatively edit your .gitconfig to contain this editor block:

    editor = cygrun -w 'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin

    The extra parameters have Notepad++ open a new window and block the calling process until it is closed, so that git receives the edited commit comment.

    Bonus: if you want to define Notepad++ as the default editor of your shell and also access it through a handy "np" alias, add these to the .bashrc file in your home directory:

    export EDITOR="'c:/Program Files/Notepad++/notepad++.exe'"
    alias np="'c:/Program Files/Notepad++/notepad++.exe'"

    Remember to be very careful with the line endings, when creating new files and use the Edit -> EOL Conversion.

    The cygrun script:

    #!/bin/bash
    #
    # Run a program, converting UNIX and Windows format path arguments.
    #
    # Install in Cygwin's `bin` dir or elsewhere in your path. 
    # Create a symlink for convenience: `ln -s cygrun.sh cygrun`.
    #
    # Use `cygrun -w windows-program unix-path ...` to run Windows programs (e.g. from UNIX software).
    # E.g., in my .gitconfig core.editor is set to `cygrun -w 'C:/Program Files/Notepad2/Notepad2.exe'`.
    #
    # Use `cygrun [-u] unix-program windows-path ...` to run Cygwin programs (e.g. from Windows software).
    # Usually not needed since Cygwin translates Windows paths automatically (e.g. `ls 'C:\Windows'` works).
    # Still it can be useful in case a Windows program might produce paths that mix backslashes and forward slashes,
    # e.g. in Apache Ant `${dist.dir}/file` evaluates to `C:\path\to\project\dist/file`, which Cygwin won't
    # translate automatically. So, to deploy the file, I use `cygrun -u scp ${dist.dir}/file ${deploy.url}`.
    #
    # Use the `-b` option to detach from tty, run the process in background, and return immediately.
    #
    # There is currently a limitation on passing non-path arguments to a program. Since there is no way
    # to automatically distinguish path arguments from non-path arguments, all of the arguments are passed
    # to `cygpath`. As long as non-path arguments don't contain `/` or `\` characters, and `-a` or `-C`
    # options are not used, `cygpath` will return the arguments unmodified - no problem.
    # Due to this, the `-a` and `-C` options are disabled at the moment.
    # TODO: Add an option allowing to specify index positions of path arguments (comma-separated, support ranges).
    #
    # Most of the options are passed as is to `cygpath`, which is used for path conversion.
    
    set -e -o pipefail
    
    usage() {
      local code=${1:-2}
      test $code -ne 0 && exec >&2
      
      echo "Usage: $(basename "$0" .sh) [options] program [argument]..."
      echo
      echo 'Run a program, converting UNIX and Windows format path arguments.'
      echo
      echo 'Output type options:'
      echo
      echo '  -d, --dos             print DOS (short) form of NAMEs (C:\PROGRA~1\)'
      echo '  -m, --mixed           like --windows, but with regular slashes (C:/WINNT)'
      echo '  -u, --unix            (default) print Unix form of NAMEs (/cygdrive/c/winnt)'
      echo '  -w, --windows         print Windows form of NAMEs (C:\WINNT)'
      echo
      echo 'Path conversion options:' 
      echo
      echo '  -U, --proc-cygdrive   Emit /proc/cygdrive path instead of cygdrive prefix'
      echo '                        when converting Windows path to UNIX path.'
      echo '  -c, --codepage CP     print DOS, Windows, or mixed pathname in Windows'
      echo '                        codepage CP.  CP can be a numeric codepage identifier,'
      echo '                        or one of the reserved words ANSI, OEM, or UTF8.'
      echo '                        If this option is missing, cygrun defaults to the'
      echo '                        character set defined by the current locale.'
      echo
      echo "Other 'cygpath' options:"
      echo
      echo '  -f, --file FILE       read FILE for input; use - to read from STDIN'
      echo "  -o, --option          read 'cygpath' options from FILE as well (for use with --file)"
      echo '  -h, --help            output usage information and exit'
      echo
      echo 'Run options:'
      echo
      echo '  -b, --background      run in a new session'
      echo '  -n, --dry-run         print the command that would be executed, and exit'
      
      exit $code
    }
    
    run() {
      local -n _run_args=$2
      if test "$dry_run"; then
        test "$chdir" && printf 'cd %s\n' "$chdir"
        printf '%s\n' "$1 ${_run_args[*]}"
      else
        test "$chdir" && cd -- "$chdir"
        if test "$background"; then
          setsid "$1" "${_run_args[@]}" </dev/null &>/dev/null &
        else
          exec "$1" "${_run_args[@]}"
        fi
      fi
    }
    
    declare opts fileopts chdir background dry_run
    while test $# -gt 0; do
      case $1 in
        -d|--dos|-u|--unix|-m|--mixed|-w|--windows|-U|--proc-cygdrive|-o|--option)
          opts="${opts} $1"
        ;;
        -C|--codepage|-f|--file)
          opts="${opts} $1 $2"
          shift
        ;;
        -f|--file)
          fileopts=1
          opts="${opts} -i $1 $2"
          shift
        ;;
        -b|--background)
          background=1
        ;;
        -n|--dry-run)
          dry_run=1
        ;;
        -h|--help)
          usage 0
        ;;
        --)
          shift
          break
        ;;
        -*)
          script="$(basename "$0" .sh)"
          echo "$script: Unknown option: $1" >&2
          echo "Try '$script --help' for more information." >&2
          exit 2
        ;;
        *)
          break
        ;;
      esac
      shift
    done
    test "$chdir" && opts="$opts -a"
    
    program=$1
    test "$program" || usage
    shift
    
    declare -a args
    test $# -gt 0 -o "$fileopts" && mapfile -t args < <(cygpath $opts -- "$@" || exit 1)
    run "$program" args


    See also