Создание shared objects в *nix , аналог виндовских .dll

Люди, кто-нибудь делал .so под *nix ? Вроде пишутся они только на си или нет?
Если на си, то мне интересно:
-- как писать source, в виде обычного класса си ?
-- есть ли тут shared variables, т.е. общие переменные для всех процессов, загрузивших этот модуль?
-- каков синтаксис загрузки модулей, обращения к их функциям? (хочу обращаться к ним из perl-скриптов )

Если кто видел доки по этому делу, тоже буду рад, а то не найти мне что-то ничего

http://www.ibiblio.org/pub/Linux/docs/HOWT...rary-HOWTO.html

если не боишься английского

инглиша не боюсь, спасибо. У кого есть ещё какая инфа?

Посмотри здесь, я как раз постил про это:
Plug-in's

2lunc: спасибо, конечно, однако из всего топика понял мало
Ну да ладно завтра попробую въехать, а то я уже
если что, создаю .so для апача, компилить source предполагается apxs'ом.

Меня особо интересует shared vaiables, такое можно сделать? Чтобы переменные модуля .so были доступны для процессов сервера, в рамках которых выполняются копии моего скрипта. А если ещё добавить в .so функции для работы с shared данными... вообще сказка. Я понятно объясняю или выглядит как бред?

Да. Идея в том, что пишется суперкласс с методами доступа к переменным, которые ты хочешь расшарить. В so'шнике лежит клас наследник, с нужными переменными.

Ну а суперкласс разве не надо в so ? И чего-то я не догоняю, зачем 2 класса вообще, почему в 1 не засунуть и переменные, и методы доступа? Напиши поподробнее, если не сложно.

Добавлено в 22.01.04, 08:25:
может в асе обсудим? : #226632882

вопрос: если я попытаюсь загрузить 1 и тот же плугин нескольких процессах , получу ли я в них ссылку на 1 и ту же область памяти (или будут запускаться копии библиотеки)? смогут ли они корректно изменять переменные в плагине, не конфликтуя, ведь пользоваться ими будет несколько экземпляров?

в моём случае,я предполагал сделать так: при каждом обращении пользователя к web-серверу, запускается perl-скрипт (вернее создаётся его копия), который должен загружать so, т.е. библиотеку, в каждом должен выполняться код загрузки библиотеки, подобный твоему, только вот я не знаю перловского синтаксиса для этого.

man dlsym
man dlopen
man opendir -- это не системные функции случайно?

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

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

Если два раза загрузить библиотеку через dlopen, то будет получен указатель на одну область памятм.
Не совсем понятно зачем это делать. Если нужно несколько экземпляров объекта:
- открываете библиотеку через dlopen
- в библиотеке должен содержатся метод вроде

MyClass * get_object () {
return new MyClass;
}

MyClass - класс потомок абстрактного суперкласса.

- через dlsym получаете адрес этой функции.

get_object_func get_object;
get_object = (get_object_func) dlsym (dlopen(...), "get_object"); // Так делать не хорошо - лучше
// проверить сначала результат dlopen

- теперь вызовами типа MyAbstrClass *my_variable = get_object() можно получать нужные объектов. MyAbstrClass - абстрактный класс.

Как в web_сервере процессы работают не знаю. Но допустим есть главный процесс - в нем грузим библиотеку. Далее создаются копии этого процесса и в них уже сохдаются конкретные объекты. Сервер сам пишешь? Не понятно что должна делать библиотека...

dlopen, dlsym, etc - системные вызовы.
Вот что-то на русском: http://manpage.stsland.ru/man3/dlopen.3.html

Добавлено в 26.01.04, 14:02:
У меня тут в институте проблеммы - в аське и в сети пока очень редко появляюсь

Огромное спасибо за помощь, но даю отбой. Ибо реализация задуманного выходит слишком сложной и тяжеловесной + не могу найти доку для загрузки модулей so из перл, ведь dl*** -- это чисто сишные функции, так я понял. Вобщем перехожу на использование БД mysql, так оно проше и надёжнее будет.

Что хотел от модуля so: хранить в нём некую служебную стр-ру данных (+ методы работы с ней), содержащую указатели (вернее смещение в файле) на основные данные, получаемые при каждом запросе юзера. Это для быстрого поиска в файле, но в реализации со множеством потоков всё работало бы либо медленно, либо ненадёжно (алгоритм хорош только для 1 процесса). Я же изначально уцепился за реализацию, а не за концепцию, эх .. технология программирования отдыхает, sorry.

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

Сообщение отредактировано: lunc - 27.01.04, 11:55