Динамическое связывание в zOS - PullRequest
5 голосов
/ 09 декабря 2010

Мне нужно создать динамически связанную библиотеку в zOS.Какие параметры нужно передать компилятору.

Также, как проверить, динамически ли связана библиотека в zOS [зависит] от других библиотек.У нас есть LDD в Linux, который показывает эту связь.Есть ли у нас эквивалент «ldd» в земле zOS?

1 Ответ

2 голосов
/ 27 ноября 2015

Вы не говорите это напрямую, но я предполагаю, что вы имеете в виду C / C ++ DLL. Вы также можете создавать разделяемые библиотеки на других языках (даже на ассемблере), но шаги будут другими.

Сначала вам нужно решить, что вы хотите экспортировать. Во многих примерах IBM используется директива компилятора EXPORTALL, но имейте в виду, что это может привести к очень медленным исполняемым файлам, в зависимости от вашего стиля кодирования. Если вы не выполните EXPORTALL, вам понадобится #pragma export для всего, что вы хотите экспортировать (код или данные). Не забывайте, что вы можете экспортировать данные (переменные), а также исполняемые функции ... иногда вам это нужно для обмена данными с функциями DLL.

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

Когда вы связываете свою DLL, не забудьте указать опцию -Wl, DLL (есть много способов ... эта часть отличается, если вы связываете в пакетном режиме - я предполагаю, что вы встраиваете в make-файл какой-то) Ссылка будет генерировать фактическую DLL, а также «боковую деку», содержащую операторы «IMPORT» для всех ваших экспортируемых функций. Они понадобятся вам для связи с любыми клиентскими программами, которые вы ожидаете вызвать DLL. Например, если ваш импорт находится в файле с именем AAA.x, c89 -Wc, DLL myapp.c AAA.x скомпилирует вызывающий код с осознанием того, что функции в AAA.x отключены в некоторой разновидности DLL.

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

Фактически сама DLL может находиться в нескольких местах в зависимости от характера вашего приложения. Если вы дружелюбны к UNIX Services, это просто исполняемый файл в LIBPATH. Это также может быть STEPLIB, LNKLST, LPA и так далее.

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

Есть некоторые другие основные вещи, которые следует учитывать при компоновке, такие как обеспечение повторного ввода вашего кода. Большинство из них изложены в документации IBM, и если вы строите с такими вещами, как «c89» (или эквивалент), правильные опции обычно устанавливаются автоматически (на самом деле, чтобы понять, что происходит, включите на подробный вывод и посмотрите все параметры для себя).

Если вам нужно создать перекрестную ссылку на то, что называется чем-то, команда «nm» служб UNIX может предоставить вам эту информацию. Если вы создаете подробные списки с редактированием ссылок, все данные также будут там, когда вы создаете свои библиотеки DLL.

Удачи!

...