Аналог dll в linux

Обновлено: 03.07.2024

Есть ли что-нибудь похожее?
Задача такая: нужно создать набор однотипных модулей (в каждой - по одной функции
которые должны будут обнаруживаться основной программой в момент её запуска.

Хотя бы сказали, как их делать.
P.S. А я почему-то считал, что это статические библиотеки

если по-простому, то
gcc -shared -fPIC -o plugin.so plugin.c
а по-другому я и не умею

man dlopen еще пригодится.

> man dlopen еще пригодится.
Наконец-то правильный ответ. Неужели кто-то думал, что человеку станет легче если он узнает, что вместо букв .dll буквы .so?

Неужели кто-то думал, что человеку станет легче если он узнает, что вместо букв .dll буквы .so?

RTFM
google "dynamic linking"
man ld
man ld.so (man ld-linux.so)
man ldd
man ldconfig
man dlopen
man gcc

man ld
man ld.so (man ld-linux.so)
man ldd
man ldconfig
man dlopen
man gcc
Не хочу тубя огорчать, но ссылки на эти статьи я уже видел в "man dlopen"
Не хочу тубя огорчать, но ссылки на эти статьи я уже видел в "man dlopen"
малаца, возьми с полки пирожок
для того там эти ссылки и написаны, чтобы ты их видел и читал соответствующие статьи, а не задавал мегабоянные, расписанные на каждом столбе, вопросы в форуме.
А что интересно меня в этом должно "огорчать"?

В сети (или в инете) можно скачать книжку Programming Linux Games. Там коротко и ясно рассказано про DLL под Linux. Рекомендую.

Взято где-то здесь
Будет на примере показано, как создавать библиотеки: статические, разделяемые и динамические.
Создание статической библиотеки
Файл libhello.h содержит прототип библиотечной функции
void hello(void);
Файл libhello.c содержит реализацию библиотечной функции

Файл demo_use.c содержит вызов библиотечной функции.

Объектный файл libhello.o создается без проблем. При попытке создать библиотеку получаем ошибку
gcc -g -shared -Wl,-soname,libhello.so.1 -o libhello.so.1.0 libhello.o -lc
libhello.o: In function `_init':
/home/zubr/demo_library/shared/libhello.c multiple d

ну ты бы еще man'ы сюда запостил


Это типа как пример "хорошего ответа" на твой первый пост?
Простыня из серии "программирование для начинающих". Да статья неплохая, но не думал же ты, что кто-то тебе напишет нечто подобное в этом треде.
Да, и такие статьи (учебного характера) есть в сети, и справочной информации тоже навалом. Теперь ты знаешь, как искать нужную тебе информацию (раз это нашел поздравляю.

Подскажите , есть ли аналог в линуксах виндовских динамических библиотек . Либо чем их в тех осях заменяют.
Либо , смысловой аналог .

*.so файлы (so = shared object). это и есть "дллки по юниксоидному".

По моему это ДЛЛ убогий аналог .so.
Уж больно криво делали свою работу ребята из Мелкософта.

Че криво раскажи в dll против so, я в линуксе мало шарю.

Ок , спасибо всем.

А правда, что если .so кинуть в одну папку с программкой, то она эту .so не найдёт? )

JohnSmith
Правда. Линкер ищет либы в путях, указанных в его кэше, потом в дефолтовых /lib и /usr/lib.
Можно форснуть свой путь установкой переменной окружения LD_LIBRARY_PATH.
Но никогда so'шка не ищется в текущем каталоке без явного на то указания. Все-ж, потенциальная дырка.

_vasa_
В SO экспортируется все и без проблем и без телодвижений
В DLL с эти проблемы

> Че криво раскажи в dll против so, я в линуксе мало шарю.
Существует понятие DLLHELL в вендах: когда разные программы используют разные версии дллки, а название то у них одно. И все эти проги пихают эти дллки в одну папку - system32, естественно они заменяют дру друга, нарушая работу других программ. Чтобы бороться с этим, программисты не придумали ничего лучше как хранить дллки в папке своей программы, откуда программа их и грузит. При этом теряется основное преимущество длл - это уже не разделяемая библиотека, т.е. каждая программа, которая использует такую блиблиотеку, будет загружать в память свою копию, нагло пожирая память. В линуксе используется другой подход - к имени разделяемой библиотеке присоединяется её версия, и проблема отпадает.

RPGman
>Правда. Линкер ищет либы в путях, указанных в его кэше, потом в дефолтовых /lib
>и /usr/lib.

А для чего линкеру .so? Это тогда уже .lib, а не .dll аналог.

>А для чего линкеру .so? Это тогда уже .lib, а не .dll аналог.
1. Наверное, подразумевался в данном случае dl (dynamic linker).
2. А ты разве .lib не скармливаешь линкеру в винде при использовании функций из dll ?

Ni3
>1. Наверное, подразумевался в данном случае dl (dynamic linker).
>2. А ты разве .lib не скармливаешь линкеру в винде при использовании функций из dll ?

2. Это не обязательно ведь.

В никсах не то, что динамические библиотеки в текущей директории не ищутся, а даже простой бинарник из текущей директории не запускается, только с указанием полного пути к нему. Но главное преймущество so библиотек в никсах, сказали выше - можно запросто экспортировать классы из них, без всяких лишних телодвижний. В этом плане статические библиотеки (а на самом деле это архивы с .o файлами) вполне равноправны с динамическими. Ну а Microsoft, как всегда пошел своим путем.

Executor
>А для чего линкеру .so? Это тогда уже .lib, а не .dll аналог.
Dynamic linker. Винда с dll'ями то же самое делает, линкует с ехешником в рантайме :)

Игры, созданные с использованием Unity3D для Linux, содержат .dll файлы в папке с данными GameDataFolder/Managed .

Что странно, потому что я думал, что Linux использует .so файлы вместо .dll файлов.

(То же самое относится и к приложениям Android-Unity3D.)

Обратите внимание, что у вас также есть несколько бесплатных приложений (не только игр) на основе Mono Framework, доступных в репозиториях Ubuntu. Например: сорванец.

Также обратите внимание, что расширения файлов, в том числе .dll и .so , не имеют смысла в Linux. Они используются только для нашего удобства. @ray Можешь объяснить? Я думал, что они все еще являются стандартом для передачи информации о типе файла, поэтому не бессмысленны? @FynnMazurkiewicz: Это скорее вопрос слегка отличающихся традиций проектирования, чем одного центрального атрибута, который применяет любая из систем. Фактически, и ядро Windows, и динамический компоновщик Linux с удовольствием загрузят совместно используемую библиотеку (в их соответствующих форматах) независимо от того, оканчивается ли ее имя на .dll или .so или что-то еще. По историческим причинам LoadLibrary в системный вызов Windows , в некоторых случаях будет добавить «.dll» к имени файла , если он не имеет расширение уже, но это не так, как это обычно используется . @ray не совсем: gcc не найдет предоставленную библиотеку, например, -lm если имя ее файла не заканчивается .so или .a или ее версионные варианты.

Эти .dll файлы GameDataFolder/Managed принадлежат к родной код программы , которая использует Mono внутренне.

Игровой движок Unity встраивает Mono (даже на большинстве платформ Windows).

Как игровой движок Unity использует Mono

Другие ситуации, когда вы можете увидеть .dll файлы на Ubuntu

Были описаны две ситуации, когда вы можете увидеть .dll файл в Ubuntu:

Есть два других достаточно распространенных случая, когда вы можете увидеть .dll файл в Ubuntu:

Это не попытка исчерпывающего перечисления всех обстоятельств, когда вы можете столкнуться с .dll Ubuntu. (Например, это также может быть библиотека OS / 2. ) Однако я считаю, что эти четыре случая являются наиболее распространенными.

Как вы знаете каждая программа, установленная на вашем компьютере, состоит из нескольких частей. Это непосредственно исполняемый файл, который вы запускаете через терминал, а также библиотеки с набором функций, которые может использовать программа.

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

В этой статье мы подробно рассмотрим что такое библиотеки Ubuntu, как их устанавливать, где брать и что делать если библиотека установлена, а программа говорит что ее нет. Мы не будем трогать создание библиотек, это совсем не наша тема. Как обычно, начнем с теории.

Что такое библиотеки

Библиотеки в Linux содержат наборы функций или если сказать проще алгоритмов или действий для решения определенных задач. Например, если программе нужно вывести строку на экран она не начинает сама закрашивать нужные пиксели, а просто обращается к отвечающей за это функции из библиотеки, то же самое если программе нужно прочитать содержимое файла, она не работает с секторами жесткого диска, ей достаточно вызвать функцию из стандартной библиотеки с (libc.so) и передать ей в параметрах имя нужного файла, а библиотека уже вернет ей запрашиваемые данные.

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

Не нужно думать что библиотеки есть только в Linux, в Windows они тоже есть, только имеют другой формат и расширение dll. В Linux же все библиотеки находятся в папах /lib/, /usr/lib, /usr/local/lib или для 64 битных систем также появляется папка lib64 во всех этих подкаталогах, для библиотек специфичных для этой архитектуры. Библиотека имеет расширение .so и ее название начинается со слова lib. Например, libfuse.so, libc.so.

Дальше, после расширения файла .so идет номер версии библиотеки. Номер версии меняется всякий раз, когда разработчики вносят в нее изменения ломающие совместимость со всеми рассчитанными на нее программами. В таком случае в системе будут уже две библиотеки и каждая программа будет использовать правильную версию. Например, glibc.so.6 и glibc.so.5.

Если интересно можно даже посмотреть какие библиотеки и каких версий, использует та или иная программа, например:

linux-vdso.so.1 (0x00007ffd99167000)
libmount.so.1 => /usr/lib64/libmount.so.1 (0x00007f0f6beb0000)
libc.so.6 => /lib64/libc.so.6 (0x00007f0f6bb08000)
libblkid.so.1 => /usr/lib64/libblkid.so.1 (0x00007f0f6b8c8000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f0f6b6a4000)
/lib64/ld-linux-x86-64.so.2 (0x000055aca8227000)
libuuid.so.1 => /usr/lib64/libuuid.so.1 (0x00007f0f6b49f000)
libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x00007f0f6b238000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f0f6b034000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f0f6ae17000)

Также эта информация может быть полезна при создании портативных версий программ. А теперь давайте рассмотрим как устанавливаются библиотеки в Ubuntu.

Установка библиотек в Ubuntu

Обычно, если вы используете менеджер пакетов вашего дистрибутива для установки новых программ, то библиотеки устанавливаются автоматически. Но если вы хотите собрать программу из исходников или запустить 32 битную программу на 64 битной системе могут начаться проблемы. Например, при запуске или компиляции программы вы получаете ошибку:

error while loading shared libraries: xxxx.so.0
cannot open shared object file no such file or directory

Обычно, в Ubuntu имена пакетов библиотек соответствуют имени нужной библиотеки. Поэтому чтобы определить точное имя в большинстве случаев достаточно воспользоваться поиском по базе пакетов:

apt search libfuse

library

Как видите, найдено два варианта библиотеки, libfuse2 и libfuse-dev.

Если библиотека нужна обычной программе и ее не нужно собирать из исходников, то будет достаточно установить библиотеку ubuntu без префикса dev. Например:

sudo apt install libfuse2

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

sudo apt install libfuse-dev

Много проблем может вызвать ситуация, когда вам нужно запустить 32 битную программу в 64 битной системе. Например, если вы установили 64 битную версию библиотеки, а программа все равно говорит о том, что не может ее найти, возможно это 32 битная программа и ей необходима именно 32 библиотека. Если программа не устанавливается с помощью пакетного менеджера, вам тоже придется устанавливать библиотеки вручную.

Посмотреть разрядность бинарника можно с помощью утилиты file:

library3

На скриншоте показаны два варианта вывода программы, для 32 бит, в нашем случае Skype и для 64 - mount.

Для того чтобы установить библиотеку Ubuntu с архитектурой i386 сначала необходимо добавить поддержку архитектуры i386 в dpkg:

sudo dpkg --add-architecture i386

Затем обновляем наши репозитории:

sudo apt update

А во время установки нужной вам библиотеки теперь необходимо указать архитектуру через двоеточие после имени пакета:

sudo apt install libfuse-dev:i386

library1

Если вы уверенны, что библиотека установлена, но программа все равно говорит, что такой библиотеки нет, то возможно, ей просто нужна другая версия библиотеки. Например, в системе есть libudev.so.0, а программе нужна libudev.so.0.1. Такое случается, если вы попытаетесь установить пакет для другого дистрибутива, особенно в Red Hat системах. Если в репозиториях нет нужной версии библиотеки, то скорее всего, они одинаковы, и можно просто создать символическую ссылку:

ln -s /lib/libudev.so.0 /lib/libudev.so.0.1

Затем программа найдет нужную библиотеку.

Управление библиотеками в Linux

Установка библиотек ubuntu уже рассмотрена, но хотелось бы упомянуть еще пару моментов. Как я сказал, библиотеки ubuntu размещаются в определенных каталогах, но расположение библиотек можно настроить.

Перед тем как библиотека будет подключена к программе, ее должна найти в системе специальная программа - менеджер библиотек. Он берет адреса библиотек из файла /etc/ld.cache, а этот файл формируется утилитой ldconfig, на основе файлов конфигурации /etc/ld.so.conf.

В этом файле перечислены все пути к библиотекам. Если вы хотите добавить свою папку для библиотек просто добавьте ее в этот файл:

Затем обновите кэш просто выполнив:

Теперь ваша библиотека может быть загружена программой, например, вы можете добавить путь /opt/lib или даже /home/user/lib. И система будет нормально грузить оттуда библиотеки.

Посмотреть какие библиотеки находятся в кеше ld.cache можно командой:

Также мы можем проверить находится ли там определенная библиотека:

ldconfig -p | grep libjpeg

library2

Еще один способ указать программе где нужно искать библиотеки - это переменная LD_LIBRARY_PATH. Например:

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

Выводы

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

Сегодня мы поговорим о библиотеках в Linux (подозреваю также, что многие описанные здесь вещи возможны и в других *nix-операционных системах, но это требует проверки :-) ).

1) Статические библиотеки (создание с помощью Assembler, C/C++; подключение и использование в программах на Assembler,C/C++);
2) Динамические библиотеки (создание с помощью Assembler, C/C++; подключение и использование в программах на C/C++l, Python).

1) Статическая библиотека - это такая библиотека, которая связывается (линкуется) с программой в момент компиляции оной. При этом объектный код библиотеки помещается в исполняемый файл программы. С этой точки зрения статическая библиотека похожа на исходный код программы, с которой она связывается, за исключением того, что библиотека компилируется "кем-то еще" и программист, использующий библиотеку, имеет дело исключительно только с результатом этой компиляции.

В Linux, как правило, файл-статическая_библиотека имеет расширение ".a"

2) Статические библиотеки на языке C.

Исходный код библиотеки:

Сохраните его в файле static.c

Ключевое слово extern необходимо для того, чтобы функция была видна в программе.

Теперь скомпилируем (! без линковки) библиотеку:

gcc -c static.c -o static.o
(на выходе имеем файл static.o, содержащий объектный код нашей библиотеки)

ar rc libMY_STATIC.a static.o

ar упаковывает несколько (! Это важно. Дело не ограничивается только одним объектным файлом) объектных файлов в одну статическую библиотеку. Статическая библиотека имеет расширение ".a", при этом ее название должно начинаться с "lib" (дань традиции).
Параметры ar:
r - предписывает заменять старые версии объектных файлов новыми - необходим для переупаковки библиотеки;
c - создать статическую библиотеку, если та еще не существует.

Проиндексируем функции внутри библиотеки для более быстрой линковки:

Итак, мы получили статическую библиотеку libMY_STATIC.a.

Теперь попытаемся использовать библиотеку в нашей программе:

Исходный текст программы (C):

Сохраните его в файле program1.c

Способы связывания библиотеки и программы:

- Скомпилируем и слинкуем (в том числе с нашей библиотекой) нашу программу:

gcc program1.c libMY_STATIC.a

(предполагается, что в качестве аргумента gcc будут переданы полные пути (!) к вашим библиотекам)

На выходе получим:

- Скомпилируйте с помощью команды:

gcc program1.c -L. -lMY_STATIC -o a1.out

- путь к каталогу, содержащему наши библиотек (используйте "-L

- название нашей библиотеки (это важно - название (!), а не имя файла - собственно, если библиотека имеет своим именем "libBLABLABLA.a", то ее названием будет "BLABLABLA" - т.е. имя без приставки "lib" и расширения ".a") (для нескольких библиотек используйте "-l -l . ")

Запустите файл a1.out на выполнение и удостовертесь, что результаты те же, что и в предыдущем пункте.

- Видоизменим предыдущий способ - уберем аргументы "-L":

В начале проверим значение переменной LD_LIBRARY_PATH и содержимое файла /etc/ld.so.conf:

echo $LD_LIBRARY_PATH ; cat /etc/ld.so.conf

На экране появился некоторый список каталогов - это те каталоги, в которых система ищет библиотеки при их линковке с программой (еще к таким каталогам относятся:
/lib
/usr/lib
. Поместите libMY_STATIC.a в один из этих каталогов:

(Я, к примеру, засуну нашу библиотеку в каталог /usr/lib):

su -c 'cp libMY_STATIC.a /usr/lib'
(в Ubuntu - sudo cp libMY_STATIC.a /usr/lib )
ldconfig
(ldconfig обновляет кеш данных о библиотеках линковщика)

Теперь скомпилируем и запустим нашу программу:

gcc program1.c -lMY_STATIC -o a2.out
./a2.out

Бинго! Кстати, таким вот способом вы можете подключать к своей программе любые статические библиотеки из приведенных выше каталогов.

* Бывает полезно определить все прототипы функций библиотеки в некотором заголовочном файле, который будет потом включаться в вашу программу. Это не обязательно, но удобно.

3) Статические библиотеки на языке Assembler.

Представьте, что вам необходимо оптимизировать выполнение некоторых действий в вашей программе. Разумеется, вы может применить ключевое слово asm (если пишите программу на C/C++), но лучшим решением будет создание оптимизированной вами библиотеки на языке Assembler и подключение ее к вашей программе. Давайте попробуем:

*Кстати, углубляться в процесс компиляции библиотеки и ее линковки с вашей программой я не буду (!). Этот процесс идентичен полностью (!) тому же процессу для библиотек, написанных на языке C.

Итак, имеем вот такую программу:

Сохраните ее в файле program2.c

Скомпилируйте ее и запустите:

Я привел этот пример, чтобы показать действительно возможность оптимизации программы с помощью библиотеки на Assembler'е. Вы можете заметить, что вызов printf в main() не оптимален, т.к. printf, по крайней мере, один раз использует цикл while для поиска вхождений конструкций "%. " в строку. Это не оптимально, т.к. очевидно, что таковых символов у нас нет. Оптимизируем нашу программу с помощью библиотеки на Assebmler'е:

my_printf:
movl $4,%eax
xorl %ebx,%ebx
incl %ebx
movl $hw,%ecx
movl $hw_e,%edx
int $0x80
xorl %eax,%eax
ret

Сохраните исходный код библиотеки в файле static2.s

Это AT&T наречие Assembler'а.

Теперь получим библиотеку:

gcc -c static2.s -o static2.o
ar rc static2.a static2.o
ranlib static2.a

На выходе имеем статическую библиотеку static2.a

Теперь напишем программу, использующую эту статическую библиотеку (язык C):

Сохраните текст программы в файле program3.c

Заметьте, я добавил прототип библиотечной функции для удобства.

Скомпилируем и слинкуем программу с библиотекой, после чего запустим программу на выполнение:

gcc program3.c static2.a
./a.out

На выходе получим:

* Принцип линкования статических библиотек с программами на Assembler'е аналогичен принципу для программ на C. Просто, когда будете использовать статические библиотеки в Assembler'е, помните о соглашениях C по передаче аргументов в функцию и возвращению результата.

4) Статические библиотеки на языке C++.

Принцип создания аналогичен статическим библиотекам на C, но перед каждой экспортируемой функцией не забывайте добавлять:

(экспортировать как функцию на C - т.е. без расширения имен).

* Кстати, используйте g++ вместо gcc, если захотите протестировать приведенные выше примеры.

Подключение к вашей программе аналогично подключению к программе, написанной на C, за исключением необходимости явно добавлять к тексту программы прототипы импортируемых функций в следующем виде:

extern "C" PROTOTYPE

Где PROTOTYPE - прототип импортируемой функции.

* При подключении статических библиотек на C++ к программе на C сопряжено с некоторыми трудностями - т.к. при компиляции и линковки программы необходимо будет также вручную подключить системные библиотеки для реализации функционала, предоставляемого библиотекой Standart C++ сверх того, что предоставляет библиотека Standart C.

Динамические библиотеки (shared).

1) Динамическая библиотека - библиотека, подключаемая к программе в момент выполнения. Это означает, что при создании библиотеки производится не только ее компиляция, но и линковка с другими, нужными ей, библиотеками (!).

Динамические библиотеки полезны в случаях, если:
- Важно не перекомпилировать всю программу, а только перекомпилировать ту часть, которая реализует определенные функции - тогда эти функции выносятся в динамическую библиотеку;
- Важно использовать в программах на C библиотеки, подготовленные на C++ и при этом избежать лишних трудностей с линковкой программы;
- Кроме того, динамические библиотеки позволяют экономить место на жестком диске и в оперативной памяти, если одна и таже библиотека используется несколькими программами.

В Linux, обычно, динамические библиотеки имеют расширение ".so".

2) Подготовим исходный код динамической библиотеки (пример на C++).

Исходный код динамической библиотеки по принципам создания ничем (!) не отличается от исходного кода статических библиотек.

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

Итак, исходный код библиотеки (C++):

extern "C" int hello()
cout<<"Hello world!\n I'm function hello()"<<endl;
return 0;
>

Сохраните приведенный код в файле dynamic.cpp.

* Кстати, внутри динамической библиотеки вы можете описать следующие функции:
void _init() - будет вызвана при инициализации динамической библиотеки (загрузки ее в память);
void _fini() - будет вызвана при выгрузке из памяти динамической библиотеки.

3) Компиляция и линковка динамических библиотек.

Давайте получим динамическую библиотеку:

Получим файл с объектным кодом:

g++ -fPIC -c dynamic.cpp -o dynamic.o

(используйте gcc для программ на С и Assembler'е)

-fPIC - использовать относительную адресацию в переходах подпрограмм - во избежание конфликтов при динамическом связывании

А теперь из объектного файла получим библиотеку:

g++ -shared -olibdynamic.so dynamic.o

(используйте gcc для программ на С и Assembler'е)

libdynamic.so - имя результирующей библиотеки;
-shared - предписывает создать динамическую (т.е. "разделяемую") библиотеку.

* Именуйте динамические библиотеки следующим способом:

Итак, на выходе мы имеем libdynamic.so - нашу динамическую библиотеку.

4) Использование динамической библиотеки в программе на C/C++.

- Связывание с библиотекой во время компиляции программы (C/C++):

------ Подготовим исходный код нашей программы:

Сохраните его в файле Dprogram1.c

extern "C" int hello();

Сохраните его в файле Dprogram1.cpp

(единственное отличие, как вы можете заметить, в ключевом слове extern - см. часть 1 пункт 4)

------ Теперь добьемся того, чтобы система смогла найти нашу библиотеку. Поместим libdynamic.so в один из каталогов:

cat /etc/ld.so.conf
и выполните потом " ldconfig "

------ И, наконец, скомпилируем программу и слинкуем ее с библиотекой:

gcc ИСХОДНИК -lИМЯ_БИБЛИОТЕКИ -o РЕЗУЛЬТИРУЮЩИЙ_БИНАРИК

В нашем случае: gcc Dprogram1.c -L/home/amv/c/libs/ -ldynamic

(используйте g++ для программы на C++)

Запустим на исполнение полученный файл:

В итоге должно получится:

- Связывание с библиотекой во время исполнения программы (C/C++):

Разумеется, предыдущий пример неплох. Однако бывает необходимо подключать библиотеку во время выполнения программы. Для этого можно использовать функционал из заголовочного файла .

Исходный код примера (C):

Сохраните его в файле Dprogram2.c

В dlfcn.h определены следующие функции:

* Посмотрите на досуге вот этот перевод "man dlopen": Привет, OpenNET

gcc -ldl Dprogram2.c

(используйте g++ для программы на C++)

Запустим на исполнение полученный файл:

В итоге должно получится:

* Важно! Нет необходимости помещать библиотеку в один из специальных каталогов, модифицировать переменные окружения и выполнять "ldconfig"

- Использование динамической библиотеки в программе на Python:

Все предельно просто.

------ Поместим libdynamic.so в один из каталогов:

cat /etc/ld.so.conf
и выполните потом "ldconfig"

Исходный текст программы на python'е:

Модуль ctypes входит в стандартную поставку модулей python версии 2.5 и выше.

Фуф. Мы проделали довольно большую работу, но ведь это только верхушка айсберга.

Читайте также: