LINUX.ORG.RU

Сборка Freetype-GL в Windows для mingw и символические ссылки на файлы

 , , , ,


0

1

Всех приветствую!

Хочу описать процесс сборки указанной выше библиотеки и задать вопрос. Сразу вопрос может показаться непонятным.

Итак, сборка:

  1. Имеем установленный MSYS (C:\msys64\ucrt64) плюс минимально необх. библиотеки
pacman -S mingw-w64-ucrt-x86_64-gcc
pacman -S mingw-w64-ucrt-x86_64-cmake
pacman -S mingw-w64-ucrt-x86_64-make
pacman -S mingw-w64-ucrt-x86_64-glew
pacman -S mingw-w64-ucrt-x86_64-glfw
pacman -S mingw-w64-ucrt-x86_64-fontconfig
pacman -S mingw-w64-ucrt-x86_64-freetype
pacman -S mingw-w64-ucrt-x86_64-harfbuzz
pacman -S mingw-w64-ucrt-x86_64-pkg-config
pacman -S mingw-w64-ucrt-x86_64-doxygen

установленные через шелл msys2.exe

  1. скачиваем Freetype GL https://github.com/rougier/freetype-gl/tree/master в C:\freetype-gl

  2. Читаем в INSTALL.md

 **Note**: Harfbuzz examples only work with symbolic links enabled. See <https://github.com/git-for-windows/git/wiki/Symbolic-links>

Поэтому делаем для всех файлов (кроме texture-font.h, texture-font.с, freetype-gl-err.h, freetype-gl-err.c ) в папке C:\freetype-gl\harfbuzz символические ссылки на файлы с теми же именами, но на уровень каталога выше.

(

По умолчанию создание символич. ссылок в Windows не разрешено.

Для этого включаем разрешение на создание символич. ссылок в Windows (в моем случае Windows 11).

Чтобы включить разрешение нужно запустить оснастку Group Policy Editor: Win+R gpedit.msc Конфигурация компьютера->Конфигурация Windows->Параметры безопасности->Локальные политики->Назначение прав пользователя добавляем своего user-а в пункте «Создание символических ссылок».

PS. Если такой оснастки нет, то устанавливаем ее: запускаем терминал с правами администратор и вводим: сначала

FOR %F IN ("%SystemRoot%\servicing\Packages\Microsoft-Windows-GroupPolicy-ClientTools-Package~*.mum") DO ( DISM /Online /NoRestart /Add-Package:"%F" ) 

потом

FOR %F IN ("%SystemRoot%\servicing\Packages\Microsoft-Windows-GroupPolicy-ClientExtensions-Package~*.mum") DO ( DISM /Online /NoRestart /Add-Package:"%F" )

)

Создание ссылок происходит так:

Запоминаем имя файла находящегося в C:\freetype-gl\harfbuzz, удаляем его из папки. Потом в этом каталоге выполняем

mklink <имя файла>  C:\freetype-gl\<имя файла>

Например,

mklink  freetype-gl-errdef.h C:\freetype-gl\freetype-gl-errdef.h

будет выдано

symbolic link created for freetype-gl-errdef.h <<===>> C:\freetype-gl\freetype-gl-errdef.h

Вот здесь вопрос(!?): а то делать с файлами freetype-gl-err.h, freetype-gl-err.c у которых нет в папке C:\freetype-gl аналогов с такими же именами?

Например, файл freetype-gl-err.h содержит одну строку «../freetype-gl-err.h», но уровнем выше нет файла с таким именем.

Т.е. нам нужно переделать файл в ссылку, но как будто не существует файла на который он должен ссылатся.

Это относится к этим двум файлам.

Естественно из-за этого сборка будет неудачной.

В репозитории Freetype GL в описании комита на эти файлы указано «Add harfbuzz support for errno stuff».

mkdir C:\freetype-gl\build

далее запускаем шелл C:\msys64\urct64.exe и в нем выполняем

  cd C:\freetype-gl\build

Далее возможны два варианта (все команды вып. в шелле C:\msys64\urct64.exe):

3а)

cmake -G "MinGW Makefiles"  -Dfreetype-gl_BUILD_HARFBUZZ=ON ..

потом mingw32-make

Отваливается в самом начале на:

[ 26%] Building C object harfbuzz/CMakeFiles/freetype-gl-hb.dir/platform.c.obj
[ 27%] Building C object harfbuzz/CMakeFiles/freetype-gl-hb.dir/texture-atlas.c.obj
[ 28%] Building C object harfbuzz/CMakeFiles/freetype-gl-hb.dir/texture-font.c.obj
In file included from C:\freetype-gl\harfbuzz\texture-font.c:15:
C:\freetype-gl\harfbuzz\freetype-gl-err.h:1:1: error: expected identifier or '(' before '.' token
    1 | ../freetype-gl-err.h
      | ^
C:\freetype-gl\harfbuzz\texture-font.c:26:3: warning: data definition has no type or storage class
   26 | } FT_Errors[] =
      |   ^~~~~~~~~
C:\freetype-gl\harfbuzz\texture-font.c:26:3: error: type defaults to 'int' in declaration of 'FT_Errors' [-Wimplicit-int]
In file included from C:/msys64/ucrt64/include/freetype2/freetype/fterrors.h:200,
                 from C:\freetype-gl\harfbuzz\texture-font.c:27:
C:/msys64/ucrt64/include/freetype2/freetype/fterrdef.h:58:3: warning: braces around scalar initializer
   58 |   FT_NOERRORDEF_( Ok,                                        0x00,
...

3б)

cmake -G "MinGW Makefiles"  -Dfreetype-gl_BUILD_HARFBUZZ=OFF ..

потом mingw32-make

Тут компилирует почти все примеры библиотеки, отваливается на

[ 94%] Building C object demos/CMakeFiles/markup.dir/markup.c.obj
[ 96%] Linking C executable markup.exe
C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles\markup.dir/objects.a(markup.c.obj):markup.c:(.text+0x15): undefined reference to `FcInit'
C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles\markup.dir/objects.a(markup.c.obj):markup.c:(.text+0x21): undefined reference to `FcNameParse'
C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles\markup.dir/objects.a(markup.c.obj):markup.c:(.text+0x3c): undefined reference to `FcConfigSubstitute'
C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles\markup.dir/objects.a(markup.c.obj):markup.c:(.text+0x48): undefined reference to `FcDefaultSubstitute'
C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles\markup.dir/objects.a(markup.c.obj):markup.c:(.text+0x60): undefined reference to `FcFontMatch'
C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles\markup.dir/objects.a(markup.c.obj):markup.c:(.text+0x70): undefined reference to `FcPatternDestroy'
C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles\markup.dir/objects.a(markup.c.obj):markup.c:(.text+0xc5): undefined reference to `FcPatternGet'
C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles\markup.dir/objects.a(markup.c.obj):markup.c:(.text+0x113): undefined reference to `FcPatternDestroy'
collect2.exe: error: ld returned 1 exit status
mingw32-make[2]: *** [demos\CMakeFiles\markup.dir\build.make:112: demos/markup.exe] Error 1
mingw32-make[1]: *** [CMakeFiles\Makefile2:902: demos/CMakeFiles/markup.dir/all] Error 2
mingw32-make: *** [Makefile:145: all] Error 2

Но можно сказать уже успех.

Делитесь своими мыслями по поводу описанного.

Кто как собирает с меньшими издержками?

Что делать со ссылками непонятно куда?

Заранее благодарен за содержательные комментарии.


Ответ на: комментарий от MirandaUser2

Проверил:

mklink  freetype-gl-err.h C:\freetype-gl\freetype-gl-err.h
mklink  freetype-gl-err.c C:\freetype-gl\freetype-gl-err.c

Отвалилось на этапе cmak-а:

-- Configuring done (14.7s)
CMake Error at harfbuzz/CMakeLists.txt:53 (add_library):
  Cannot find source file:

    freetype-gl-err.c

  Tried extensions .c .C .c++ .cc .cpp .cxx .cu .mpp .m .M .mm .ixx .cppm
  .ccm .cxxm .c++m .h .hh .h++ .hm .hpp .hxx .in .txx .f .F .for .f77 .f90
  .f95 .f03 .hip .ispc


CMake Error at harfbuzz/CMakeLists.txt:53 (add_library):
  No SOURCES given to target: freetype-gl-hb


CMake Generate step failed.  Build files cannot be regenerated correctly.

Ну так не очень хорошо создавать ссылки на что-то, что возможно есть надежда, сгенерится..

Gyros
() автор топика
Ответ на: комментарий от Gyros
[ 97%] Linking C executable harfbuzz
/usr/bin/ld: ../harfbuzz/libfreetype-gl-hb.a(vertex-attribute.c.o): warning: relocation against `log_error' in read-only section `.text'
/usr/bin/ld: ../harfbuzz/libfreetype-gl-hb.a(texture-atlas.c.o): in function `texture_atlas_get_region':
texture-atlas.c:(.text+0x536): undefined reference to `log_error'
/usr/bin/ld: ../harfbuzz/libfreetype-gl-hb.a(texture-atlas.c.o): in function `texture_atlas_special':
texture-atlas.c:(.text+0x5ed): undefined reference to `log_error'
/usr/bin/ld: ../harfbuzz/libfreetype-gl-hb.a(texture-atlas.c.o): in function `texture_atlas_new':
texture-atlas.c:(.text+0x7ee): undefined reference to `log_error'
/usr/bin/ld: texture-atlas.c:(.text+0x832): undefined reference to `log_error'
/usr/bin/ld: ../harfbuzz/libfreetype-gl-hb.a(vector.c.o): in function `vector_new':
vector.c:(.text+0x7c): undefined reference to `log_error'
/usr/bin/ld: ../harfbuzz/libfreetype-gl-hb.a(vertex-buffer.c.o):vertex-buffer.c:(.text+0x3b1): more undefined references to `log_error' follow
/usr/bin/ld: warning: creating DT_TEXTREL in a PIE
collect2: error: ld returned 1 exit status
make[2]: *** [demos/CMakeFiles/harfbuzz.dir/build.make:114: demos/harfbuzz] Error 1
make[1]: *** [CMakeFiles/Makefile2:994: demos/CMakeFiles/harfbuzz.dir/all] Error 2
make: *** [Makefile:146: all] Error 2

Походу harfbuzz там давно никто не тестил.

arax ★★
()
Ответ на: комментарий от Gyros

Вероятно там что то криво линкуется, но в cmake ковыряться лень.
Простое решение: во все си файлы в каталоге harfbuzz, после секции с инклюдами добавить:

#define log_error(error, ...) { }
Тогда соберется, но я правда под линукс проверял.

arax ★★
()
Последнее исправление: arax (всего исправлений: 1)

Запишу у себя что винда не умеет в симлинки, будет ещё один способ испортить жизнь виндузятникам, пытающимся пользоваться моим кодом. В дополнение к двоеточиям в именах файлов, нечувствительности к регистру и файлами prn и con.

anonymous
()
Ответ на: комментарий от anonymous

cmake там поправить не проблема, нужно всего лишь добавить ftgl-utils.h и ftgl-utils.с в harfbuzz/CMakeLists.txt
Но это еще не все, там после этого нужно будет решить проблему с конфликтом имен функций.

arax ★★
()
Ответ на: комментарий от anonymous

В Винде реализована работа с символич. ссылками с версии Windows Vista.

Однако чтобы этим воспользоваться пришлось потратить время, выполнив дополнит. вышеописанные шаги.

Gyros
() автор топика
Ответ на: комментарий от arax

Ну нафиг этот cmake. Еще в него лезть нехватало.

Правильно М. Кутепов (tsoding) сказал где-то на ютубе, что изучение системы сборки - трата времени. Хотя кстати, видел в одной редкой книге утверждалось, что cmake не явл. системой сборки, а всего лишь генератор скриптов. Тем более.

В целом, увидев комментарий от разработчика на гитхабе, я успокоился на достигнутом. Почти все (94%) примеры собрались. Этого достаточно.

Gyros
() автор топика
Ответ на: комментарий от Gyros

Этого достаточно.

Дак пример с harfbuzz и не собрался, потому что там библиотека нерабочая.
Нафига ты указывал -Dfreetype-gl_BUILD_HARFBUZZ=ON, если тебе он не нужен?

arax ★★
()
Последнее исправление: arax (всего исправлений: 1)
Ответ на: комментарий от Gyros

Правильно М. Кутепов (tsoding) сказал где-то на ютубе, что изучение системы сборки - трата времени.

Так любое действие - трата времени. Вопрос пустая или нет. Если этот ваш кутепов утверждает что пустая, то либо он некомпетентен, либо вы его неправильно поняли, потому что кроме системы сборки ничто ваши исходники не соберёт, а вы не соберёте чужие. Есть ещё уникумы топящие за писание мейкфайлов руками, но такие быстро сливаются когда им показывают список того что нужно починить и учесть чтобы эти мейкфайлы работали за пределами их локахостов.

К сожалению, в C++ по историческим причинам сложился зоопарк этих систем сборки прошедший уже 3 поколения эволюции, и сама экосистема по тем же причинам достаточно сложна чтобы требовать настройки, потому что нет элементарно общего подхода к подключению внешней зависимости - какие-то библиотеки ставят .pc файлы, какие-то .cmake, какие-то ничего не ставят, каких-то вообще в системе нет, и они вендорятся (а не все к этому приспособлены), или подтягиваются через external_project, conan или vcpkg (это всё разные способы), причем на винде, например, работают только полтора из этих способов, поэтому от систем сборки никуда не деться. Так что систему сборки можно не любить, или любить не все из двух на данный момент топовых (cmake и meson), но потратить время на изучение и знать надо обязательно.

Хотя кстати, видел в одной редкой книге утверждалось, что cmake не явл. системой сборки, а всего лишь генератор скриптов.

Это словоблудие, что характеризует автора этой «редкой книги», потому что принципиальной разницы собирает ли система сборки сама или нет, нету. Её функция - полностью определять как собирать проект, и ровно этим она занимается, а кому выполнить готовые команды - куску ли собственного кода или внешнему make/ninja, дело десятое. Считаю что правильнее всё-таки внешнему, потому что во-первых, есть проверенные временем state of art решения для этой задачи типа ninja, во-вторых, не всегда система сборки вообще должна что-то собирать - например, она ничего не должна собирать когда нужно сгенерить проект для IDE. Поэтому логично решать общий сценарий генерации скриптов сборки для любых потребителей, чем она и занимается.

anonymous
()
Ответ на: комментарий от anonymous

Возможно вы и правы.

Просто поверхностное знакомство с cmake вызвало отторжение.

Он не показался интуитивно понятным.

Возможно надо почитать про нему что-то серьезное, а не отрывки из форумов.

В конце концов ведь что-то вызвало его (cmak-а) к жизни.

Gyros
() автор топика
Ответ на: комментарий от Gyros

Что можно быть интуитивно понятнее чем

find_package(зависимость)
add_executable(приложение исходники)
target_link_libraries(приложение зависимость)

ни одной лишней сущности, ни одной лишней строчки, при этом сложно описать какой объём сложности и нюансов тут инкапсулирован для этого чтобы это работало везде. Но есть нюанс - это если зависимость писали адекватные люди и она ставит cmake файл. А если нет, но то, конечно, привет неинтуитивность, но источник её не cmake, а болото которым является экосистема C/плюсов. А так читайте modern cmake, потому что cmake будучи первым представителем последнего поколения сборочных систем тоже нелёгкий путь развития прошёл. На а не cmake, так meson, не важно, Главное не слушайте если вам кто-то предлагает майкфайлы писать.

anonymous
()
Ответ на: комментарий от anonymous

Запишу у себя что винда не умеет в симлинки, будет ещё один способ испортить жизнь виндузятникам, пытающимся пользоваться моим кодом.

скорее, не умеет msys2 без дополнительных приседаний.
как-то еще под Win7 у меня база установленных пакетов pacman была симлинками на другой диск.

симлинки в винде можно реализовать тремя разными способами: Junction point, mklink, ln и Alt-F6 в FAR который кажется NTFS junction point.

mklink появился только в новых виндах. сами скрипты bash/msys/msys2/mingw должны быть написаны правильно чтобы обрабатывать случай readlink.

еще они не совсем правильно отрабатывают права на запись, например в msys2 если сделать $HOME симлинком можно получить readonly.

был момент, когда в Win7 msys2 работал правильно – примерно 4-5 лет назад или даже на 1-2 года раньше. потом с каким-то обновлением нормальная поддержка симлинков сломалась в новых версиях msys2.

что касается того как именно работают все эти NTFS junction point, mklink, ln и Alt-F6 в FAR – это отдельный разговор.

подозреваю, что не все эти костыльные случаи обрабатываются в скриптах как самого msys2 так и отдельных проектов.

так что да, симлинки в винде – это отличный способ выстрелить себе в ногу на ровном месте. как и пути с пробелами или кириллическими буквами или прочим юникодным эмодзи.

anonymous
()