Код библиотек.
Зачем нам нужен extern «C»? Строго говоря, не нужен, потому что по умолчанию GCC (нынешняя версия, по крайней мере), экспортирует все функции и они доступны для использования, но есть один нюанс. Можно закомментировать эту строчку, пересобрать библиотеку и вместо увидеть ошибку «./libfoo2.so: undefined symbol: foo». То есть функция dlsym не находит символа «foo» в библиотеке, хотя мы точно знаем, что он там есть. С помощью nm мы просмотрим таблицу экспорта нашей библиотеки:
$ nm -D ./libfoo2.so 0000000000201028 B __bss_start w __cxa_finalize 0000000000201028 D _edata 0000000000201030 B _end 00000000000006b4 T _fini w __gmon_start__ 0000000000000548 T _init w _ITM_deregisterTMCloneTable w _ITM_registerTMCloneTable w _Jv_RegisterClasses U puts
0000000000000733 T _Z10foo_deinitv 0000000000000720 T _Z8foo_initv
00000000000006a0 T _Z3foov
Вот эта последняя строчка «_Z3foov» и есть имя нашей экспортированной функции и это очевидно не то же самое, что «foo». Теперь раскомментируем строчку extern «C», пересоберем библиотеку и запустим nm еще раз:
Writing reusable Jenkins Pipeline code | Jenkins Shared Library | Advanced Jenkins Pipeline Tutorial
$ nm -D ./libfoo2.so 0000000000201028 B __bss_start w __cxa_finalize 0000000000201028 D _edata 0000000000201030 B _end 000000000000075c T _fini 0000000000000746 T foo w __gmon_start__ 00000000000005d0 T _init w _ITM_deregisterTMCloneTable w _ITM_registerTMCloneTable w _Jv_RegisterClasses U puts 0000000000000733 T _Z10foo_deinitv 0000000000000720 T _Z8foo_initv $
Теперь мы видим «foo» и у нас все опять работает:
./main Hello world! Init shared library 1 Hello, I’m a shared library 1 Init shared library 2 Hello, I’m a shared library 2 Deinit shared library 1 Deinit shared library 2
Это все связано с правилами наименования экспортируемых функций, можо погуглить «name mangling», а extern «C» принудительно заставляет компилятор именовать функции по простым и ясным правилам языка C.
Что же насчет __attribute__ ((visibility(«default»))), то по умолчанию все функции и так имеют видимость default, но, во избежание всяких неожиданностей типа нестандартных флагов компилятора, мы добавляем этот флаг в каждую экспортируемую функцию.
Сборка библиотек.
Компилируем и создаем из объектного файла shared object двумя отдельными командами.
Компиляция:
gcc -c -Wall -Werror -fpic foo1.cpp
Все нюансы тут состоят в использовании флага pic (Position Independent Code), что необходимо для динамически загружаемых библиотек (статические библиотеки не нуждаются в таком флаге).
Сборка происходит так:
gcc -shared -o libfoo1.so foo1.o
gcc -Wall -Werror -o libfoo1.so -shared -fpic foo1.cpp
тут используется специальный флаг shared для создания динамических библиотек. То же самое одной командой:
gcc -Wall -Werror -o libfoo1.so -shared -fpic foo1.cpp
Сборка main.
Все как обычно, но линкуем библиотеку dl, которая содержит dlopen, dlsym, dlclose и прочие фукции:
Getting Started With Shared Libraries in Jenkins
gcc -o main main.cpp -ldl
Настройка окружения и запуск.
В linux библиотеки лежат в строго определенных местах и откуда-то еще их загрузить не получится (в отличии от Windows), поэтому, когда мы запустим программу в первый раз, мы увидим что-то такое:
$ ./main ./libfoo1.so: cannot open shared object file: No such file or directory $
Чтобы добавить новый путь, делаем следующее:
export LD_LIBRARY_PATH=$PWD
В bash переменная окружения PWD хранит текущую папку. Теперь все работает.
2 комментария:
Великолепно! Теперь бы заставить CODELITE компилировать и собирать, что бы каждый раз в командную строку не лазить) Ответить Удалить
Все, настроил, пришлось сначала выбрать статическую библиотеку при создании проекта, затем в настройках поменять на динамическую.
Все ключи компиляции для динамической библиотеки (-fpic -shared) автоматически вставляются, прописывать не надо. Во вкладке General только прописал желаемый выходной файл lib$(ProjectName).so Удалить
Источник: myworkonly.blogspot.com
Разделяемые библиотеки (shared libraries) (lib share gcc ldd elf)
Разделяемые библиотеки (shared libraries) — это такие библиотеки,
которые загружаются приложениями при запуске. Если такая библиотека
установлена правильно, то все приложения, запускаемые после установки
библиотеки, начинают использовать эту новую разделяемую библиотеку. На
самом деле, всё гораздо гибче и соверщеннее, ибо линуксовая их
реализация позволяет:
* совершенствовать библиотеки, продолжая поддерживать программы,
использующие более старые версии этих библиотек, не совместимые с
новыми.
* заменять какие-то конкретные библиотеки или даже конкретные
функции в библиотеке во время выполнения какой-то конкретной
программы.
* проделывать всё это «на горячую», когда программа запущена и
какие-то библиотеки уже использует.
Соглашения.
Чтобы разделяемые библиотеки всё это умели, они должны соответствовать
определённым нормам. Нужно разбираться в том, что называется soname и
real name и как эти понятия связаны, также в том, где в файловой
системе разделяемые библиотеки должны лежать.
Имена разделяемых библиотек.
Каждая разделяемая библиотека имеет специальное имя, называемое
«soname». Оно имеет префикс «lib», само имя библиотеки, также слово
«.so», за которым следует номер стадии и номер версии библиотеки,
которые меняются каждый раз, когда у библиотеки меняется интерфейс.
(Особое исключение: библиотеки низкого уровня языка С не начинаются с
«lib»). Полное имя soname включает в качестве префикса имя дериктории,
в которой библиотека находится. На живых системах полное имя
библиотеки — это просто символическая ссылка на имя real name
разделяемой библиотеки.
Также, каждая разделяемая библиотека имеет имя real name. Это — имя
файла, содержащего собственно код библиотеки. Real name в дополнение к
soname содержит номер стадии, минорный номер (minor number), второй
номер стадии и номер релиза. Второй номер и номер релиза не
обязательны (are optional). Минорный номер и номер релиза дают вам
знать, какие именно версии библиотек установлены у вас в системе.
Кстати, в документации на библиотеку эти два последних номера могут с
библиотечными своими собратьями не совпадать.
Далее. У библиотеки существует ещё один тип имени, который
используется системой, когда библиотеку запрашивают. Называется оно
linker name, которое на самом деле равно soname, но без указания
версии.
Способ содержания разделяемых библиотек в хозяйстве состоит в
различении их по именам. Каждое приложение должно помнить о
разделяемой библиотеке, которая ему нужна, помня только soname этой
библиотеки. Наоборот, когда вы разделяемую библиотеку создаёте, вы
имеете дело только с именем файла, содержащего более детальную
информацию о версии. Когда вашу библиотеку будут устанавливать, её
запишут в один из специально предназначенных для этого каталогов в
файловой системе и запустят программу ldconfig. Эта хитрая программа
смотрит в упомянутые специальные каталоги и создаёт soname-имена как
символические ссылки к реальным именам, публикуя новости с фронтов в
файле /etc/ld.so.cache (речь об нём позже).
ldconfig не создаёт linker-имена. Обычно это делается при
инициализации библиотеки и linter-имена создаются просто как
символические ссылки к последним актуальным soname-именам или к
последним актуальным real-именам. Я бы рекомендовал делать объектом
ссылки soname-имена, ибо меняются они реже, чем real-имена. А причина,
по которой ldconfig автоматически не простраивает linker-имена в том,
чтобы дать юзверям возможность запустить код, который выбирает
lintker-имя библиотеки на своё усмотрение.
Таким образом, /usr/lib/libreadline.so.3 — это полное имя soname,
которое на самом деле является символической ссылкой на реальное имя
типа /usr/lib/libreadline.so.3.0. Linker-имя будет выглядеть как
/usr/lib/libreadline.so, являющееся символической ссылкой на
/usr/lib/libreadline.so.3
Как используются библиотеки.
На GNU системах, использующих glibc, включая все Linux, запуск ELF
бинаря приводит к запуску загрузчика. На Linux загрузчик называется
/lib/ld-linux.so.X, где X — это номер версии. Загрузчик этот находит и
загружает все разделяемые библиотеки, используемые запускаемым
ELF-бинарём (приложением).
Список директорий, в которых ищутся разделяемые библиотеки хранится в
файле /etc/ld.so.conf. Многие Red Hat-овые дистрибутивы по дефолту не
включают /usr/local/lib в файл /etc/ld.so.conf. Это выглядит багом, и
добавление /usr/local/lib + /etc в /etc/ld.so.conf — это общепринятая
заплатка, требующаяся для запуска многих прог под Red-Hat-дистрами.
Если вы хотите заменить только некоторые функции в библиотеке, оставив
какую-то часть библиотеки в строю, вам нужно записать имена библиотек
(файлы «*.o») с заменающими функциями в файл /etc/ld.so.preload. Так
вы поднимаете приоритет заменяющих библиотек над стандартными. Этот
предзагрузочный файл обычно используется для срочных заплаток.
Дистрибутивораспространители обычно плюют на него.
Чтобы как-то разгрузить процесс старта бинарей ELF от рытья в
каталогах, используется кеширование. Софтина ldconfig по дефолту
читает /etc/ld.so.conf, создаёт все нужные символические ссылки и
создаёт файл /etc/ld.so.cache, который далее используется другими
программами. Эта замануха охрененно ускоряет доступ к либам. Фишка в
том, что ldconfig запускается при добавлении DLL, удалении DLL или
когда список каталогов с DLL-ами поменялся. Запуск ldconfig-а часто
является одним из шагов, выполняемых пакетными менеджерами при
установке библиотеки. Далее при запусках софтин динамический загрузчик
юзает уже /etc/ld.so.cache, загружая либы по мере надобности.
Однако FreeBSD юзает слегка другие имена файлов для этого кеша. Во
фрях, ELF кеш — это /var/run/ld-elf.so.hints и a.out-овый кеш — это
/var/run/ld.so.hints. Они также ведаются софтиною ldconfig, так что
различие в именах файлов будет не по барабану только в особых
ситуациях.
Переменные окружения.
LD_LIBRARY_PATH
Для какого-то конкретного запуска приложения, можно подменить
библиотеки. В Linux переменная окружения LD_LIBRARY_PATH — это список
отделённых двоеточиями имён каталогов, где библиотеки следует искать
перед тем, как их будут искать по стандартным путям. Полезно для
отладки новых библиотек или для использования нестандартной библиотеки
для чего-то этакого. Переменная окружения LD_PRELOAD содержит список
разделяемых библиотек, содержащих функции, замещающие стандартные.
LD_PRELOAD работает как /etc/ld.so.preload. Эти две переменные
окружения нюхаются загрузчиком /lib/ld-linux.so. Следует отметить, что
LD_LIBRARY_PATH работает не во всех Unix-системах. Например в HP-UX
LD_LIBRARY_PATH заменена на SHLIB_PATH, а в AIX заменена на LIBPATH.
Синтаксис тот же — список, разбитый двоеточьями.
Другая полезная переменная окружения для GNU C загрузчика — это
LD_DEBUG. Она меняет режим работы всех dl* функции так, что они
начинают выдавать довольно подробную информацию о своих действиях.
Например, закиньте в LD_DEBUG строку «files» и вызовите какую-нибудь
софтину, к примеру, «ls», допустим, корня.
export LD_DEBUG=files
ls /
Помимо самого вывода ls вы увидите некоторую кухню работы ld —
используемые файлы и библиотеки при загрузке библиотек, по которым
можно судить о завивимостях, о том, какие SO-файлы загружаются и др.
Это был вывод при «files». А ещё есть «bindings» — показывает
информацию о запрашиваемых именах подпрограмм, переменных — так
называемые symbols — символы, идентификаторы; «libs» показывает
каталоги, в которых библиотеки ищутся; «versions» показывают
зависимости по версиям. Установка LD_DEBUG равной «help» с вызовом
какой-то программы, покажет доступные опции. Опять таки, LD_DEBUG не
применяется для мирных целей.
Другие переменные окружения.
Есть куча других, влияющих на загружаемый/запускаемый процесс. Имена
их начинаются с «LD_» или «RTLD_». Большинство предназначены для
низкоуровневой отладки процесса загрузчика или для реализации
сверхспособностей. Большинство недокументированы. Лучший путь познать
их — курить исходники загрузчика (он — часть gcc).
Установленный у некоторых программ setuid/setgid плюс рычаги контроля
за динамически загружаемыми библиотеками в руках пользователя —
это потенциально опасно. Поэтому GNU-загрузчик (загружает большинство
программ) игнорирует или сильно ограничивает свои возможности во время
запуска таких программ. Если у приложения различаются UID и EUID или
GID и EGID, загрузчик полагает, что у программы установлен
setuid/setgid и запрещает самому себе делать некоторые вещи. Если
будете читать исходники библиотеки GNU glibc, вы сможете это увидеть.
Обазательно посмотритие elf/rtld.c и sysdeps/generic/dl-sysdep.c.
Переменные окружения имеют полный вес, когда равны UID и EUID, GID и
EGID. Различные UNIX-подобные системы ведут себя здесь различно, но с
одной идеей: программа с установленным setuid/setgid не должна быть
чрезмерно влиятельной из-за особым образом установленных переменных
окружения.
Создание разлеляемых библиотек.
Это просто. Сначала создайте объектные файлы посредством флага gcc
-fPIC или -fpic. Флаги -fPIC и -fpic разрешают генерацию
«позиционно-независимого кода» (position independent code),
требующегося для разделяемых библиотек. Передайте soname-имя
библиотеки опцией gcc -Wl. Эта опция передаёт параметр линкеру.
gcc -shared -Wl,-sonzme,your_soname, -o library_name file_list library_list
Запятые после -Wl — не опечатка. Вы не должны включать в опцию
пробелы без обратных слешей перед ними.
А сейчас пример, в котором создаются два объектных файла, — a.o
и b.o, и, затем, разделяемая библиотека, составленная комбинацией этих
файлов.
gcc -fPIC -c a.c
gcc -fPIC -c b.c
gcc -shared -Wl,-soname,libmystuff.so.1 -o libmystuff.so.1.0.1 a.o b.o -lc
На что здесь следует обратить внимание:
* Не делайте обработки strip над готовой библиотекой и не
используйте опцию компилятора -fomit-frame-pointer пока не
приспичит. Работать такая библиотека будет, но отладка её
затруднится.
* Не забывайте использовать -fPIC или -fpic. Какую из них выбрать
— это определяется целью. -fPIC работает всегда, но даёт
больший объём кода, чем -fpic (Запомнить это свойство просто: PIC
«крупнее» pic!). Применение -fpic обычно приводит к генерации
меньшего и шустрейшего кода, но он будет иметь некоторые
платформенно-зависимые ограничения вроде количества глобально
видимых символов или размера всего кода. Но линкер вам сообщит,
если код не будет влезать. Когда линкер пристаёт, я пишу -fPIC.
* В некоторых случаях при создании объектного файла понадобится
включить опцию gcc «-Wl,-export-dynamic». Обычно таблица
динамических символов содержит только те символы, которые
используются динамическим объектом. Эта опция (при создании файла
ELF) добавляет все символы в таблицу динамических символов (зырь
ld(1) for more information). Эта опция хороша для создания
библиотек с «обратной зависимостью». Это когда динамически
загружаемая библиотека содержит неудовлетворённые символы, которые
по соглашению должны быть определены в самих приложениях, которые
эти библиотеки загружают. Для жизнеспособности идеи «обратной
зависимости», символы приложения, использующего такие библиотеки,
должны быть выполнены динамически доступными. Кстати, вы могли бы
дать опцию «-rdynamic» вместо «-Wl,export-dynamic», если
компиляция делается для Linux. Но согласно документации на ELF,
флаг «-rdynamic» не всегда работает для gcc в других системах.
Обычно, когда человек разрабатывает разделяемую библиотеку, он
тестирует её на узком круге каких-то приложений. Ему не нужно, чтобы
оставшееся большое количество приложений в системе видело её. Поэтому
при сборке программы, с которой тестируется библиотека, этой программе
можно показать, где библиотеку искать опцией линкера «rpath». Для gcc:
Если вы используете эту опцию при создании программы, с которой вы
библиотеку тестируете, то с переменной окружения LD_LIBRARY_PATH иметь
дело не придётся.
Установка и использование разделяемой библиотеки.
Проще всего — скопировать в один из стандартных каталогов (например
/usr/lib) и запустить ldconfig(8).
Сначала вы должны создать разделяемую библиотеку где-либо. Затем вам
понадобится создать необходимые символические ссылки, в частности
ссылку soname, показывающую на реальное имя (также ссылку soname, на
которой нет версии, то есть, soname оканчивающееся на «.so» для
пользователей, которым версия вокруг табуретки). Простейший способ:
ldconfig -n каталог с разделяемыми библиотеками
Наконец, когда вы собираете ваши программы, вам нужно указать линкеру
используемые вами статические и разделяемые библиотеки. Для этого есть
флаги -l и -L. Если вы не устанавливаете библиотеку в какой-то из
стандартных каталогов, вам нужно оставить их где угодно, но показать
на них своей программе. Это делается несколькими способами: флаг gcc
«-L», флаг «-rpath», переменные окружения (например LD_LIBRARY_PATH,
содержащий список каталогов, разделённых двоеточием, в которых будут
предприниматься попытки найти нужную разделяемую библиотеку перед
попытками искать её в стандартных каталогах). Если вы используете
bash, то можете вызывать свою программу так:
Если своей библиотекой вы хотите заменить только часть функций, можете
сделать это так: создать замещающий объектный файл и установить
LD_PRELOAD. Функции из этого объектного файла заместят только те же
самые функции (не касаясь остальных).
Обычно вы можете заменять библиотеки без специальных предупреждений.
Если новая библиотека реализует изменения в API, тогда автор
библиотеки меняет soname. Таким образом, в одной системе могут
сосуществовать несколько библиотек, но каждая программа в системе
находит нужные ей. Если же программа сломалась при замене библиотеки,
при которой сохранилось старое её soname, вы можете заставить
программу использовать старую версию библиотеки. Для этого скопируйте
старую библиотеку куда-нибудь, затем переименуйте программу (например
прибавьте к старому имени «.orig»), после чего создайте небольшой
«обёрточный» скрипт. Он будет устанавливать переменные окружения,
сообщающие загрузчику альтернативный путь для поиска библиотек и затем
запускать переименованную копию программы. Вот такой:
#!/bin/sh
export LD_LIBRARY_PATH=/usr/local/my_lib:$LD_LIBRARY_PATH
exec /usr/bin/my_program.orig
Строго говоря, ничего нового, просто код, порождённый компилятором C++
может вызывать функции очень удивительным образом. Вот список того,
чего нельзя делать в С++, надеясь на сохранение бинарной
совместимости:
Ни одного комментария? Будешь первым :).
Источник: 8gamers.net
Создание общей библиотеки Linux
Библиотека — это коллекция реализаций поведения, написанная на определенном языке и обладающая продуманным интерфейсом, с помощью которого это поведение активируется. К примеру, разработчики, желающие написать высокоуровневую программу, могут вместо повторяющейся реализации системных вызовов использовать для их создания библиотеку. Кроме того, это поведение предоставляется для повторного использования многими независимыми программами (Wikipedia).
Зачем
В мире открытого программного обеспечения Linux является, пожалуй, лидирующей системой. Согласно английской Wikipedia, примерно на 80% серверов интернета установлена та или иная форма Linux/Unix. Сегодня поддержка этой ОС закладывается в основу большого числа проектов. Участие в создании или расширение имеющихся опенсорсных продуктов является наиболее эффективным способом быстрой разработки программ.
В этой статье мы рассмотрим основы разработки библиотеки Linux на С++, подготовив вас к переходу в мир открытого ПО.
Как
Для начала потребуется выбрать дистрибутив и либо установить его непосредственно на ПК, либо использовать через виртуальную машину. В этом руководстве я буду использовать Ubuntu Linux 22.04. В качестве редактора кода я выбрал VS Code, который можно найти в приложении Snap Store, предлагающем удобный способ скачивания и установки наиболее популярного ПО. А ведь еще недавно единственным способом установки программ в Ubuntu был ввод команд из терминала.
И хотя установка ПО через терминал несколько медлительна, сам по себе этот инструмент является незаменимым помощником для разработчиков. Использование терминала в сочетании с горячими клавишами позволяет делать все быстрее, не отводя рук от клавиатуры.
Создание проекта в VS Code
Для быстрого запуска терминала нажмите ⊞ Win или ⌘ Cmd на клавиатуре Mac и введите terminal , нажмите Enter. После открытия терминала нужно создать каталог для проекта по следующему пути:
mkdir ~/Desktop/linux-shared-library
Теперь используем терминал для открытия созданного проекта в VS Code. Здесь можно задействовать сокращенную команду !$ , чтобы автоматически подставить часть ~/Desktop/linux-shared-library из команды выше и передать ее в редактор кода. Вот как это делается:
code !$
Теперь у вас должно открыться окно VS Code, и можно приступать.
В VS Code имеется встроенный терминал для упрощения доступа. Этот терминал можно автоматически активировать нажатием Ctrl + ~ .
Пишем main
Откройте терминал VS Code и создайте файл:
code main.cpp
Запишите в него следующий код:
// Позволяет ссылаться на встроенные функции ввода/вывода // стандартной библиотеки.
#include
// Реализация функции: int (возвращаемый тип), main (имя // функции), void (тип параметра)
int main(void)
// Используем стандартную библиотеку для вывода в окно терминала.
puts(«Hello Earth!»);
// Выходим с кодом возврата 0, обозначающим успех.
return 0;
>
Это программа, которая будет потреблять библиотеку.
Далее мы скомпилируем и выполним только что написанный код с помощью компилятора gcc, поставляемого вместе с дистрибутивом Ubuntu. Устанавливается он так:
gcc main.cpp
Вышеприведенная команда сгенерирует файл a.out , который при выполнении командой ./a.out в терминале VS Code будет выводить “Hello Earth!”:
Вы только что скомпилировали и выполнили программу С++! Далее мы разберем, как писать код, которым можно будет делиться с миром.
Написание общей библиотеки
Создайте через терминал VS Code новый файл:
code mars.cpp
В этот файл внесите следующий код:
// Позволяет ссылаться на встроенные функции ввода/вывода // стандартной библиотеки.
#include
// Определение функции: void (возвращаемый тип), foo (имя функции), // void (тип параметра).
void mars(void)
// Используем стандартную библиотеку для вывода в окно терминала
puts(«Hello Mars!»);
>
Это уже код нашей библиотеки.
Дальше нужно создать заголовочный файл. В заголовочных файлах мы определяем, какие функции библиотека будет раскрывать ее потребителям:
code mars.h
Добавьте в него следующий код:
// Определяем макрос препроцессора, чтобы mars.h включался только // раз.
#ifndef mars_h__
#define mars_h__
// Экспортируем функцию mars в библиотеку, делая доступной для // других проектов.
extern void mars(void);
#endif // mars_h__
Далее нужно скомпилировать код библиотеки, чтобы ее могла использовать программа main.cpp . Это делается в два шага: сначала компилируем код в mars.cpp в виде позиционно-независимого кода, чтобы его можно было добавить в общую библиотеку:
gcc -c -fpic -o mars.o mars.cpp
В результате будет создан объектный файл mars.o . Этот файл мы используем для создания библиотеки:
gcc -shared -o libmars.so mars.o
Теперь можно использовать его в программе main. cpp .
Интегрирование библиотеки
Добавим в main.cpp следующее:
// Позволяет ссылаться на встроенные функции ввода/вывода // стандартной библиотеки.
#include
+#include «mars.h»
// Реализация функции: int (возвращаемый тип), main (имя функции), // void (тип параметра).
int main(void)
// Используем стандартную библиотеку для вывода в терминал.
puts(«Hello Earth!»);
+ // Вызываем функцию в общей библиотеке.
+ mars();
// Выходим с кодом возврата 0, означающим успех.
return 0;
>
Здесь мы описали процесс использования функции mars из общей библиотеки.
Теперь скомпилируем программу main и свяжем ее с библиотекой mars . Компилятор gcc предполагает, что имена файлов общих библиотек должны начинаться с lib , поэтому нужно указать, что мы хотим провести линковку с libmars.so . Делается это так:
gcc main.cpp -lmars
Еще нужно сказать gcc, где искать libmars.so . Попробуем снова, но уже с аргументом -L , указывающим расположение библиотеки. О том, что файл доступен в данном каталоге, можно сообщить gcc так:
gcc -L./ main.cpp -lmars
Запускаем скомпилированную программу:
./a.out
Она не может загрузить созданную нами библиотеку. Просто мы не указали, откуда общие библиотеки нужно загружать. Делается это с помощью -Wl,-rpath :
gcc -L./ -Wl,-rpath=./ main.cpp -lmars
Вот и все! Запускайте скомпилированную программу и убедитесь, чтобы вывод совпал со следующим:
Если вы вдруг захотите перейти на следующий уровень создания общих библиотек, то подумайте о написании такой для Unreal Engine.
- Язык C: введение и настройка среды
- Как компилировать ZXing C++ в Wasm, используя WASI SDK в Linux
- Чем отличается C++ от C#?
Читайте нас в Telegram, VK и Дзен
Источник: nuancesprog.ru