Розробка/Збірка на Windows
TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate
Вибір хоста / цільової системи
Оскільки 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:
|
Встановлення 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: Якщо ви хочете зробити це складним шляхом, продовжуйте читати.
|
Встановлення 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.
Створення файлу проекту для 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
Відомі проблеми
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:
- Start certmgr
- proceed to Own Certificates
- Remove expired certificate
- Repeat the tests
- 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
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
See this stack overflow question and mail thread starting from this message for more information.
.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
- 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)".
- In a Cygwin shell inside the bin directory, give this command to create a symbolic link:
ln -s cygrun.sh cygrun- Give this command in your home directory:
git config core.editor "cygrun -w 'C:/Program Files/Notepad++/notepad++.exe' --wait"or alternatively edit your .gitconfig to contain this editor block:
editor = cygrun -w 'C:/Program Files/Notepad++/notepad++.exe' --waitThe --wait is important, as it forces git to wait until you close the file.
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