Dll libraries in linux

Dll libraries in linux

Здравствуйте, Alexey_VL, Вы писали:

>Пытась найти ответ на winehq.org, но пока безуспешно.

Сам сейчас поэксперементировал, получилось вот что.
Нашел в интернете готовую Windows DLL — из руководства, как делать DLL в Windows (http://www.flipcode.com/archives/Creating_And_Using_DLLs.shtml).
Взял оттуда код, который загружает DLL и выполняет из неё функции, немного подрихтовал и получил вот что:

Собирать при помощи вот такой команды:

На выходе будет файл с названием dllrun.exe, запускать его.

	От:	Alexey_VL
	Дата:	19.10.09 09:58
Оценка:

	От:	Sheridan
	Дата:	19.10.09 10:35
Оценка:

Приветствую, Alexey_VL, вы писали:

Можно озвучить — для чего? Что в той длл такого?

	От:	Alexey_VL
	Дата:	19.10.09 11:07
Оценка:

S>Можно озвучить — для чего? Что в той длл такого?

В DLL драйвер под Виндос для устройства на СОМ-порте, который можно самостоятельно написать и под Linux, но это потребует времени. Задача как можно быстрее начать работать с устройством для демонстрации оного. В дальнейшем уже можно будет сделать нормально, написав драйвер под Linux. Ну и вообще для общего развития интересно — неужели нет проги-эмулятора, позволяющей работать с виндовскими длл-ками в Линуксе, с учетом существования WINE

	От:	rising_edge
	Дата:	19.10.09 11:13
Оценка:

Здравствуйте, Alexey_VL, Вы писали:

S>>Можно озвучить — для чего? Что в той длл такого?

A_V>В DLL драйвер под Виндос для устройства на СОМ-порте

А оная DLL небось через драйвер COM-порта работает? И как вы собираетесь виндовой DLL лазить в устройство через линуксовый драйвер COM-порта?

	От:	Sheridan
	Дата:	19.10.09 11:17
Оценка:

	От:	LuciferSaratov
	Дата:	19.10.09 11:24
Оценка:

Здравствуйте, Alexey_VL, Вы писали:

A_V>Я так понимаю, что мне winelib не подойдет, потому что у меня Linux-приложение, которое я не могу скомпилировать как виндовское с помощью Winelib. Исходников dll-ки у меня тоже нет.

Насколько я понимаю, вот эти самые winegcc и wineg++ никоим образом не запрещают использовать обычные линуксовые библиотеки и системные вызовы. Т.е. если собирать программу при помощи winegcc, то можно использовать как WinAPI, так и линуксовые API.
Код, необходимый для инициализации WINE, winegcc генерирует сам.

	От:	Alexey_VL
	Дата:	19.10.09 11:32
Оценка:

_>А оная DLL небось через драйвер COM-порта работает? И как вы собираетесь виндовой DLL лазить в устройство через линуксовый драйвер COM-порта?

Хм, а собственно почему виндовой? Я так понимаю WINE подменяет вызовы виндос длл-ок на свои реализации. Думаю kernel32 входит в число длл-ок вызовы которых заменили.

	От:	Alexey_VL
	Дата:	19.10.09 11:41
Оценка:

S>А демонстрацию лучше на виндах демонстрируйте, раз уж там готовое есть.

Суть в том, что продемонстрировать надо работу Linux-программы. Так что виндос тут не подходит.

AVL>>Ну и вообще для общего развития интересно — неужели нет проги-эмулятора, позволяющей работать с виндовскими длл-ками в Линуксе, с учетом существования WINE
S>А оно надо? Оно ненадо. Да и вредно.

Хм, ну мне вот сейчас например надо. И судя по количеству аналогичных вопросов в нете, не только мне. Это может и не здорово для использования как архитектурное решение, но в плане временно поставить стороннюю длл-ку в свое Линукс приложение при портировании очень даже неплохо — можно сразу смотреть что получается.

	От:	Alexey_VL
	Дата:	19.10.09 11:47
Оценка:

LS>Насколько я понимаю, вот эти самые winegcc и wineg++ никоим образом не запрещают использовать обычные линуксовые библиотеки и системные вызовы. Т.е. если собирать программу при помощи winegcc, то можно использовать как WinAPI, так и линуксовые API.
LS>Код, необходимый для инициализации WINE, winegcc генерирует сам.

Угу, дочитал Wine-wiki до ответа на свой вопрос. А если у меня только часть исходников Linux-проги, которая используются для собирания so библиотек — никаких подводных камней не возникнет при стыковке с основной частью приложения, которая собрана обычным gcc?

	От:	LuciferSaratov
	Дата:	19.10.09 12:05
Оценка:

Здравствуйте, Alexey_VL, Вы писали:

A_V>Угу, дочитал Wine-wiki до ответа на свой вопрос. А если у меня только часть исходников Linux-проги, которая используются для собирания so библиотек — никаких подводных камней не возникнет при стыковке с основной частью приложения, которая собрана обычным gcc?

Я думаю, чтобы проблем не было, нужно итоговый исполняемый файл линковать при помощи winegcc/wineg++ — чтобы были прилинкованы все нужные библиотеки.

	От:	Alexey_VL
	Дата:	19.10.09 14:00
Оценка:

LS>Я думаю, чтобы проблем не было, нужно итоговый исполняемый файл линковать при помощи winegcc/wineg++ — чтобы были прилинкованы все нужные библиотеки.

В итоге нашел все ответы на свои вопросы в Wine-wiki. Спасиб за ссылку Вот похоже наиболее оптимальный подход для решения задачи по использованию длл-ки в Линукс приложении (из Wine-wiki):

A programmer asked Jun 2007 Wine devel]: [How can I write a shared library that uses Wine and can be called from a non-winelib app?]

S. Dossinger: your plugin, that loads the dll, needs to run in Wine’s environment in order to be able to load the dll. So you have to write a winelib dll. If the plugin is loaded as a library in your host app, the whole host app would have to be a winelib app. Not good So you can split your plugin into two parts, one is the plugin that runs in the host app, the other one is a seperate winelib application that runs in a seperate process and loads the win32 dll. That way the dll gets the virtual memory setup it needs. The two parts of your plugin can use any Unix IPC techniques you feel like using — sockets, pipes, shared memory, semaphores, whatever. You could forward function calls using pipes, transport bigger blobs using shared memory, and synchronise everything using semaphores(and implicit pipe synchronisation).

Источник

Блог радиста

Блог о Linux в частности и Open Source в общем, о программировании и немного о M$ Windows

Статические и динамические библиотеки в Linux

Статические и динамические библиотеки в Linux

Сегодня мы поговорим о библиотеках в 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 будут переданы полные пути (!) к вашим библиотекам)

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

Hello world! I’m static library
Return code: 0

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

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

Hello world! I’m static library
Return code: 0

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

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

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’а.

.globl my_printf — «my_printf» описывается как глобальная (видимая в других объектных файлах) последовательность
my_printf: — начало описание функции my_printf
movl $4,%eax — поместим 4 в eax (4 — номер системного вызова write)
xorl %ebx,%ebx и incl %ebx — поместим в ebx единицу — номер STDOUT
movl $message,%ecx — в ecx запишем адрес начала сообщения
movl $message_l,%edx — в edx поместим адрес конца сообщения
int $0x80 — произведем системный вызов write
xorl %eax,%eax — в eax — код возврата (0)
ret — вернемся в вызывающую процедуру
.data — секция данных (разумеется, мы могли бы передавать выводимую строку как параметр, но тогда вычисление ее конца потребовало бы от нас дополнительных усилий, что, согласитесь, лениво 🙂 )

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

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 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):

int main()
<
void *handle = dlopen(«libdynamic.so»,RTLD_LAZY);
int(*fun)(void) = dlsym(handle,»hello»);
int x = (*fun)();
dlclose(handle);
printf(«Return code: %d\n»,x);
return 0;
>;

######################

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

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

void* dlopen(«PATH_AND_NAME»,FLAG) — загружает в память динамическую библиотеку с полным именем PATH_AND_NAME и возвращает ее описатель (HANDLE) (NULL в случае неудачи). FLAG — флаги, описанные в «man dlopen»;
void* dlsym(HANDLE,»NAME») — возвращает указатель на функцию/переменную, импортируемую из библиотеки;
int dlclose(HANDLE) — выгружает библиотеку из памяти;
const char *dlerror() — получить сообщение о последней возникшей ошибке (NULL — если ошибок не произошло с момента последнего вызова dlerror).

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

gcc -ldl Dprogram2.c

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

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

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

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

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

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

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

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

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

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

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

Источник