OberonCore
https://forum.oberoncore.ru/

Linux Console: выбор реализации пускача и способ запуска
https://forum.oberoncore.ru/viewtopic.php?f=133&t=4089
Страница 1 из 3

Автор:  Alexander Shiryaev [ Понедельник, 10 Сентябрь, 2012 15:24 ]
Заголовок сообщения:  Linux Console: выбор реализации пускача и способ запуска

BlackBox можно запустить сейчас 3-мя способами: 2 -- на основе DevElfLinker (динамическая загрузка libBB.so на этапе выполнения и статическая связка на этапе сборки (компоновки) исполняемого файла), 1 -- на основе LinLinker.

Каждый из способов имеет свои достоинства и недостатки.

1) DevElfLinker, динамическая загрузка libBB.so на этапе выполнения исполняемого файла (загрузчика / "пускача").
Преимущества:
  • простая сборка исполняемого файла загрузчика ("пускача");
  • основан на DevElfLinker, который написан на Компонентном Паскале, а не на Си;
  • для сборкки исполняемого файла не требуется наличие libBB.so, следовательно, он может быть собран независимо от libBB.so;
  • см. здесь
Недостатки:
  • DevElfLinker создаёт не исполняемый файл, а библиотеку; для запуска BlackBox необходим ещё загрузчик ("пускач") этой библиотеки;
  • необходимость выполнения SetKernelBaseStack;
  • SetKernelBaseStack нужно выполнить до выполнения секции INIT модуля Kernel (и уж тем более до выполнения StdLoader.INIT).

2) DevElfLinker, связка libBB.so с исполняемым файлом на этапе компоновки исполняемого файла.
Преимущества:
  • простая сборка исполняемого файла загрузчика ("пускача");
  • основан на DevElfLinker, который написан на Компонентном Паскале, а не на Си;
  • не нужно выполнять SetKernelBaseStack.
Недостатки:
  • DevElfLinker создаёт не исполняемый файл, а библиотеку; для запуска BlackBox необходим ещё загрузчик ("пускач") этой библиотеки;
  • на этапе сборки исполняемого файла необходимо наличие libBB.so;
  • см. здесь.

3) LinLinker.
Преимущества:
  • сразу создаёт исполняемый файл загрузчика ("пускача");
  • не нужно выполнять SetKernelBaseStack, т. к. BlackBox запускается непосредственно из загрузчика ("пускача"), а не через dlopen;
  • см. здесь
Недостатки:
  • основа загрузчика написан на Си;
  • нетривиальная полноценная сборка загрузчика ("пускача"). Чтобы полностю правильно его собрать, нужно скомпилировать его основу, написанную на Си; при этом нужно следить за тем, чтобы константа (#define) exeSize равнялась размеру исполняемого файла основы загрузчика.

Выводы:

Вариант 1-й, в котором необходимо выполнение SetKernelBaseStack, -- самый неудобный.
Остальные 2 варианта примерно равноценны.
DevElfLinker на КП, создающий ELF .so, против загрузчика LinLinker основа которого на Си.
Если учесть это, и если проблема на самом деле окажется в том, что DevElfLinker собирает ELF .so устаревшего формата, то предпочтение отдаётся варианту с LinLinker.

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

Отделено от viewtopic.php?f=102&t=3540&start=20

Автор:  Евгений Темиргалеев [ Понедельник, 10 Сентябрь, 2012 22:16 ]
Заголовок сообщения:  Re: ЕРТ: линуксовый рантайм ББ

Опенбагз предпочло (3) --- (1) или (2) --- и тут я полностью их поддерживаю. Мои предположения подтвердились --- никакого волшебного "ядра на КП" нету --- речь шла о старом оминковском способе --- куске StdLoader на СИ, который много сложнее всех пускачей. (3) --- самый сложный костыль и очень хрупкий.

На мой взгляд идеальное решение в текущих реалиях (2), если бы заставить его универсально работать.

Автор:  Иван Денисов [ Вторник, 11 Сентябрь, 2012 04:22 ]
Заголовок сообщения:  Re: ЕРТ: линуксовый рантайм ББ

На С написано не ядро, а StdLoader, как я понял. То есть,
Код:
/*
 * C-startup and loader for BlackBox
 * Implemented as the StdLoader.
 */

Последний вариант позволяет сохранить внешне архитектуру программного комплекса, чтобы в виде и в linux/bsd и т.п. ББ выглядел одинаково. Но вывод ясен, спасибо Александру, по большому счету — использование того или иного метода, дело вкуса. Мой вкус однозначно на стороне, который использован в Омник версии. Мне кажется, что нельзя достоверно утверждать, что у OpenBUGS был такой выбор, и они выбрали второй вариант.

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

Вот еще решил привести документацию из LinLinker, тоже немного разъясняющую, что к чему.

Цитата:
Implementation Docu

This is the linker tool for BlackBox on Linux. The code files on Windows and Linux are the same, but the linkers work differently. The linux linker is actually more of a packer. It simply packs object files together and prepends a boot loader written in C. When the application is started the boot loader reads the object files and gives the Kernel the control.

The linux linker does two important things. FIrst, it packs the object files together to one executable thus, only one file is needed. Second, it guarantees that the order in which the object files are packed is the "import order". That is, all imports of any given object file appear before the object file itself in the boot image. (Which implies that the very first object file cannot have any imports at all.)

The file format for the boot image is:

Executable = BootLoader BootImg
BootLoader = ELFExecutable
Bootimg = Header {ObjFile}
Header = FileTag version4 nofMods4 kernelname mainname newRecFP4 newArrFP4
FileTag = 3AX 4BX 5CX 6DX

ELFExecutable is a C program compiled in the ELF format and the ObjFile entries are exact copies of the object files passed to the linker.

The ELF executable is copied from the image saved in Lin/Rsrc/exe.img.


Цитата:
Документация инструмента

Это компоновщик для BlackBox на Linux. Код на Windows, Linux один и тот же, но линкеры работают по-разному.Компоновщик Linux на самом деле больше упаковщик. Он просто упаковывает объектные файлы вместе и добавляет загрузчик, написанный на языке C. При запуске приложения загрузчик считывает объектные файлы и передает управление Kernel.

Linux компоновщик выполняет две важные вещи. Во-первых, он упаковывает объектных файлы вместе, чтобы был один исполняемый файл, таким образом, только один файл необходим. Во-вторых, он гарантирует, что порядок, в котором объектные файлы упакованы является «порядком импорта". То есть, все импорты любого объектного файла возникают перед объектом самого файла в загрузочном образ. (Из чего следует, что самый первый объектный файл не может иметь никакого импорта)

Формат файла для загрузки образа:
Executable = BootLoader BootImg
BootLoader = ELFExecutable
Bootimg = Header {ObjFile}
Header = FileTag version4 nofMods4 kernelname mainname newRecFP4 newArrFP4
FileTag = 3AX 4BX 5CX 6DX

ELF-исполняемый файл — C программа компиллированная в ELF и ObjFile вхождения — точные копии объектных файлов передаваемых сборщику.

ELF -исполняемый файл копируется из образа сохраненного в Lin/Rsrc/exe.img.

Автор:  Евгений Темиргалеев [ Среда, 12 Сентябрь, 2012 09:36 ]
Заголовок сообщения:  Re: ЕРТ: линуксовый рантайм ББ

Иван Денисов писал(а):
Мне кажется, что нельзя достоверно утверждать, что у OpenBUGS был такой выбор, и они выбрали второй вариант.
Да, верное замечание. Тут я мог напутать. В открытом Оминк пакете, на котором работал Опенбагз, только DefElfLinker со сборкой Dll.

За разъяснения спасибо, Иван, но не стоило утруждать себя, я в курсе. :)

Автор:  Alexander Shiryaev [ Среда, 12 Сентябрь, 2012 16:02 ]
Заголовок сообщения:  Re: ЕРТ: линуксовый рантайм ББ

Поразбирался с Kernel.INIT

OpenBUGS Kernel.INIT:
Код:
...
IF bootInfo # NIL THEN (* запуск на основе LinLinker *)
   modList := bootInfo.modList; (* boot loader initializes the bootInfo struct *)
   SYSTEM.GETREG(SP, baseStack); (* TODO: Check that this is ok. *)
   SetOpts;
   SetCmdLine
ELSE (* запуск на основе DevElfLinker *)
   SYSTEM.GETREG(ML, modList);   (* linker loads module list to BX *)
   SYSTEM.GETREG(SP, baseStack);
   static := init IN modList.opts;
   inDll := dll IN modList.opts;
END;
(*
dllMem := inDll;
*)
Init


SetOpts:
Код:
...
   k := modList;
   WHILE (k # NIL) & (k.name # "Kernel") DO k := k.next END;
   ASSERT(k # NIL);
   static := init IN k.opts;
   inDll := dll IN k.opts
...


Это не правильно, должно быть:
Код:
static := init IN modList.opts;
inDll := dll IN modList.opts;


т.е. переменные static и inDll должны заполняться на основе opts последнего модуля в списке Linker.Link, а не Kernel.

из-за этого способ 3 -- на основе LinLinker -- не работает с ядром OpenBUGS.

строчка
Код:
SYSTEM.PUTREG(ML, SYSTEM.ADR(modList));

закомментирована в OpenBUGS Kernel.Init, т.к. ML всё равно потом нигде не используется, он нужен только для передачи modList в Kernel.INIT.

Автор:  Евгений Темиргалеев [ Четверг, 13 Сентябрь, 2012 04:58 ]
Заголовок сообщения:  Re: ЕРТ: линуксовый рантайм ББ

Евгений Темиргалеев писал(а):
На мой взгляд идеальное решение в текущих реалиях (2), если бы заставить его универсально работать.

Это решение работает, когда проверял, забыл ключ -m32 при сборке экзешника. Позавчера виделся с Александром, он напомнил, так я даже не поверил, что мог собирать без него :) Сейчас нашёл те команды сборки, ключа нет...

Но и это решение оказалось менее идеальным, чем мне казалось. Всё время путаю статическую линковку дин. библиотек --- библиотека связывается с экзешником в момент компоновки, автоматом грузится и докомпоновывается при его запуске. Т.е. библиотеку всё равно нужно иметь в доступном для системы месте, и если в винда автоматом берёт около экзешника, то линух этого просто так не делает. В своё время с этим ковырялся, с выставлением LD_LIBRARY_PATH у меня так и не получилось. Сейчас нашёл в сети ещё один вариант решения (для линуха) --- завелось.
Код:
"ert0devCmds.RewriteThis('', 'reader.c', 'utf8')"
extern void Init (void) __attribute ((stdcall));

int main (int argc, char **argv)
{
   Init();
   return 0;
}

"omcCmdline.Exec('lin')" gcc -m32 -o reader reader.c -L. libBB.so ; echo готово ; read

1) доб. библ. в системные
"omcCmdline.Exec('lin')" sudo ln -v -s -t /lib32 $PWD/libBB.so ; read
"omcCmdline.Exec('lin')" ./reader  ; echo выполнено ; read

2) запускать через линуховый загрузчик явно, указывая ему соотв. параметр
"omcCmdline.Exec('lin')" /lib/ld-linux.so.2 --library-path $PWD $PWD/reader ; read
подробнее см 3.3.1 в http://www.tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html

Раз получается, что способ (3) с LinLinker --- хотя и костыльный, но пока единственный, который позволяет получить монолитный вып. файл, то отмести его нельзя.

Итого, если кто предлагал поддерживать все способы, подписываюсь. Все они костыльные, а когда речь идёт о костылях, выбор должен оставаться за конечным разработчиком.

Автор:  Alexander Shiryaev [ Четверг, 13 Сентябрь, 2012 10:29 ]
Заголовок сообщения:  Re: ЕРТ: линуксовый рантайм ББ

По мне так 2-й способ оптимальный.

libBB.so:
Код:
DevElfLinker.LinkDll libBB.so := Kernel+ Files HostFiles StdLoader

BlackBox.c:
Код:
int main (int argc, char *argv[])
{
  return 0;
}

При запуске программы во время libBB.INIT выполнится StdLoader.INIT, который запустит Init.INIT через Dialog.Call

Как компилировать:
Код:
gcc [ -m32 ] -o BlackBox BlackBox.c -L . -lBB

Как запускать:
Код:
env LD_LIBRARY_PATH=. ./BlackBox

Автор:  Евгений Темиргалеев [ Пятница, 14 Сентябрь, 2012 08:36 ]
Заголовок сообщения:  Re: ЕРТ: линуксовый рантайм ББ

Совсем пустым пускач не будет. Нужно передавать в Kernel argc и argv. Но проблема в том, что до вызова main и Kernel инициализировался, и завершилось всё.

Имеющимся способом это будет выглядеть так (выполнение не должно идти из секции инициализации):
Код:
#include ...
void ParsToEnv (int argc, char **argv)
{
   const char * const argcId = "bb-argc";
   const char * const argvId = "bb-argv";
   int res, ok;
   char argcS[9], argvS[9];

   res = sprintf(argcS, "%08X", argc); dprintf("1: %i\n", res);
   ok = res > 0;
   if (ok) { res = sprintf(argvS, "%08X", (unsigned)argv); dprintf("2: %i\n", res); ok = res == 8; }
   if (ok) { res = setenv(argcId, argcS, 1); dprintf("3: %i\n", res);    ok = res == 0; }
   if (ok) { res = setenv(argvId, argvS, 1); dprintf("4: %i\n", res); ok = res == 0; }
   if (!ok) { fprintf(stderr, "Failed to setenv \"%s\" & \"%s\"\n", argcId, argvId); }
} /*ParsToEnv*/

int main (int argc, char *argv[])
{
  ParsToEnv(argc, argv);
  Init();
  return 0;
}

Или надо думать о другом способе передачи argc/argv, либо вообще не использовать ком. строку, а соовт. параметры работы ББ передавать каким-то другим механизмом. Например через те же переменные окружения. Но сие получится не совместимо с виндовой версией.

Отдельный вопрос из этой темы (при текущей реализации): Kernel.cmdline --- склеивание argv[i] в одну строку с разделением (например, как у оминк, пробелами) некорректно. Т.к. однозначно расклеить это дело не выйдет, поскольку метод "расклеивания" завязан на оболочку. Kernel же может использоваться только в платформенно-зафисимых модулях, то надо argc и argv, покопированный в КП-е строки (с конверсией в UCS-2) в явном виде выставлять. И соотв. переписать модули, которым нужны параметры ком. строки.

Автор:  Alexander Shiryaev [ Пятница, 14 Сентябрь, 2012 09:58 ]
Заголовок сообщения:  Re: ЕРТ: линуксовый рантайм ББ

Да, всё так...

С учётом того, как устроена Kernel.cmdline, можно просто запускать BlackBox так:
env CMDLINE="..." BlackBox
или через скрипт:
Код:
#!/bin/sh
exec env CMDLINE="$0 `echo ${@}`" BlackBox


и дальше в Kernel заполнять переменную cmdline через Libc.getenv("CMDLINE"):
Код:
PROCEDURE SetCmdLine;
   VAR x: LinLibc.PtrSTR;
BEGIN
   x := LinLibc.getenv("CMDLINE");
   IF x # NIL THEN
      cmdLine := x$
   END
END SetCmdLine;

Автор:  Евгений Темиргалеев [ Пятница, 14 Сентябрь, 2012 12:54 ]
Заголовок сообщения:  Re: ЕРТ: линуксовый рантайм ББ

Да, при использовании специфического способа запуска, что по факту есть, такое решение проще. Переводить, думаю, стоит внутри ББ. Соотв. средства в capi есть.

Однако решение со склеенной комстрокой, про которое я предлагаю подумат, не эквивроалентно обработке уже поделенной интерпретатором ком. строки. Нельзя разбить комстроку на отдельные параметры внутри ББ, поскольку нет формального и стандартного синтаксиса ком. строки. Прибавьте сюда ESC-литеры и подобное и пути с пробелами и проч. Но решение этой задачи можно пока отложить.
Код:
echo $# ${@}

 ./1 ф1 1ф
2 ф1 1ф
./1 "ф1 1ф"
1 ф1 1ф

Автор:  Alexander Shiryaev [ Пятница, 14 Сентябрь, 2012 13:31 ]
Заголовок сообщения:  Re: ЕРТ: линуксовый рантайм ББ

Евгений Темиргалеев писал(а):
Переводить, думаю, стоит внутри ББ. Соотв. средства в capi есть.

Кстати, какие?

У меня LANG=ru_RU.KOI8-R

Автор:  Евгений Темиргалеев [ Пятница, 14 Сентябрь, 2012 13:39 ]
Заголовок сообщения:  Re: ЕРТ: линуксовый рантайм ББ

Точно не помню. Смотрите около http://www.gnu.org/software/libc/manual ... Conversion

Если Вы обратите внимание, то в реализациях LinLog и LinSimpleLog используется конверсия UCS-2 -> ...
Остаётся найти обратные функции.

Автор:  Alexander Shiryaev [ Пятница, 14 Сентябрь, 2012 15:56 ]
Заголовок сообщения:  Re: ЕРТ: линуксовый рантайм ББ

У меня wctomb вообще не работает:

Код:
PROCEDURE Do*;
    VAR res: INTEGER;
        s: ARRAY [untagged] 10 OF SHORTCHAR;
        wc: Libc.wchar_t;
BEGIN
    wc := 1087; (* cyr small p *)
    res := Libc.wctomb(s, wc);
    StdLog.Int(res);
    res := Libc.printf(s);
    StdLog.Ln
END Do;

=>
Код:
 -1

Автор:  Евгений Темиргалеев [ Пятница, 14 Сентябрь, 2012 18:26 ]
Заголовок сообщения:  Re: ЕРТ: линуксовый рантайм ББ

А примеры с LinSimpleLog работают? --- поглядите LinSimpleLog.Open

Автор:  Евгений Темиргалеев [ Четверг, 27 Сентябрь, 2012 15:08 ]
Заголовок сообщения:  Re: Linux Console: структура папок, хранение материалов

выделено: viewtopic.php?p=75079#p75079
Alexander Shiryaev писал(а):
Надо написать установочный скрипт, который будет копировать нужные файлы в ${PREFIX}/BlackBox, libBB.so -- в ${PREFIX}/lib, исполняемые файлы в ${PREFIX}/BlackBox с сылками в ${PREFIX}/bin (чтобы работала опция /USE).
Озвученный Вами способ централизованной установки по правилам линуха, если я правильно Вас понял, --- неизбежен при создании пакета (например, deb) для автоматической установки.

Но для разработки он не обязателен. Виндовый ББ работает с опцией /USE безотносительно каталога его местонахождения. Для линухового же можно (ert-dev пример) и нужно обеспечить тоже.

Вариант --- запускающий скрипт (в ert-dev был пускач), мне представлялось, что мы на этом пока и остановились (viewtopic.php?p=74701#p74701, viewtopic.php?p=74718#p74718)

Автор:  Alexander Shiryaev [ Четверг, 27 Сентябрь, 2012 19:18 ]
Заголовок сообщения:  Re: Linux Console: структура папок, хранение материалов

Евгений Темиргалеев писал(а):
Alexander Shiryaev писал(а):
Надо написать установочный скрипт, который будет копировать нужные файлы в ${PREFIX}/BlackBox, libBB.so -- в ${PREFIX}/lib, исполняемые файлы в ${PREFIX}/BlackBox с сылками в ${PREFIX}/bin (чтобы работала опция /USE).
Озвученный Вами способ централизованной установки по правилам линуха, если я правильно Вас понял, --- неизбежен при создании пакета (например, deb) для автоматической установки.

Но для разработки он не обязателен. Виндовый ББ работает с опцией /USE безотносительно каталога его местонахождения. Для линухового же можно (ert-dev пример) и нужно обеспечить тоже.

Вариант --- запускающий скрипт (в ert-dev был пускач), мне представлялось, что мы на этом пока и остановились (viewtopic.php?p=74701#p74701, viewtopic.php?p=74718#p74718)


Скрипт для запуска BlackBox:
Код:
#!/bin/sh

rn=`readlink -f "${0}"`
d=`dirname "${rn}"`

env CMDLINE="${d}/BlackBox `echo ${@}`" "${d}"/BlackBox

должен находиться в основном каталоге BlackBox.
libBB.so -- в ${PREFIX}/lib
в bin -- ссылка на скрипт для запуска, представленный выше.

Тогда скрипт для запуска BlackBox будет работать, откуда бы его ни запустили, при этом не будет меняться рабочий каталог wd, т. е. cd ${PREFIX}/BlackBox в скрипте выполнять не надо, и при использовании опции /USE можно будет задавать не только абсолютые, но и относительные пути, например:
Код:
cd ~/work/BlackBox
BlackBox /USE .

Автор:  Евгений Темиргалеев [ Четверг, 27 Сентябрь, 2012 21:48 ]
Заголовок сообщения:  Re: Linux Console: структура папок, хранение материалов

Alexander Shiryaev писал(а):
Скрипт для запуска BlackBox:
Код:
#!/bin/sh

rn=`readlink -f "${0}"`
d=`dirname "${rn}"`

env CMDLINE="${d}/BlackBox `echo ${@}`" "${d}"/BlackBox
должен находиться в основном каталоге BlackBox.
libBB.so -- в ${PREFIX}/lib
в bin -- ссылка на скрипт для запуска, представленный выше.

Тогда скрипт для запуска BlackBox будет работать, откуда бы его ни запустили, при этом не будет меняться рабочий каталог wd, т. е. cd ${PREFIX}/BlackBox в скрипте выполнять не надо, и при использовании опции /USE можно будет задавать не только абсолютые, но и относительные пути, например:
Код:
cd ~/work/BlackBox
BlackBox /USE .
Всё равно деталей недопонял. Вы лучше схему пуска опишите документом ББ. Оно все равно будет нужно.

Представляю дело так: нужно обеспечить ту же схему, что и в винде. Дальше всё решают пользовательские скрипты (они же решают проблему относительных путей, если надо) --- мы пользуемся такими, которые запускают некоторый ББ из текущего каталога как рабочего (и для виндового ББ и для линухового).

Та же схема что и в винде упирается в отсутствие DevElfLinker.Link (exe). Сейчас у нас выходит такое решение (3 указанные части суть замена одного экзешника, т.е. эти файлы, в идеале один, должны лежать рядом):
1) сишный пускач, статически слинкованный с библиотекой.
2) библиотека, которая суть сам экзешник
3) скрипт (завязан на имя пускача), решаюший проблемы:
А) Kernel из библиотеки не может сам получить комстроку, берёт комстроку из переменной окружения.
Б) Надо добавить прописывание пути экзешника как пути поиска библиотеки, как Вы сами предложили.

Чего не хватает до полного описания Вашей схемы?

Автор:  Alexander Shiryaev [ Четверг, 27 Сентябрь, 2012 23:27 ]
Заголовок сообщения:  Re: Linux Console: структура папок, хранение материалов

Евгений Темиргалеев писал(а):
Alexander Shiryaev писал(а):
Скрипт для запуска BlackBox:
Код:
#!/bin/sh

rn=`readlink -f "${0}"`
d=`dirname "${rn}"`

env CMDLINE="${d}/BlackBox `echo ${@}`" "${d}"/BlackBox
должен находиться в основном каталоге BlackBox.
libBB.so -- в ${PREFIX}/lib
в bin -- ссылка на скрипт для запуска, представленный выше.

Тогда скрипт для запуска BlackBox будет работать, откуда бы его ни запустили, при этом не будет меняться рабочий каталог wd, т. е. cd ${PREFIX}/BlackBox в скрипте выполнять не надо, и при использовании опции /USE можно будет задавать не только абсолютые, но и относительные пути, например:
Код:
cd ~/work/BlackBox
BlackBox /USE .
Всё равно деталей недопонял. Вы лучше схему пуска опишите документом ББ. Оно все равно будет нужно.

Представляю дело так: нужно обеспечить ту же схему, что и в винде. Дальше всё решают пользовательские скрипты (они же решают проблему относительных путей, если надо) --- мы пользуемся такими, которые запускают некоторый ББ из текущего каталога как рабочего (и для виндового ББ и для линухового).

Та же схема что и в винде упирается в отсутствие DevElfLinker.Link (exe). Сейчас у нас выходит такое решение (3 указанные части суть замена одного экзешника, т.е. эти файлы, в идеале один, должны лежать рядом):
1) сишный пускач, статически слинкованный с библиотекой.
2) библиотека, которая суть сам экзешник
3) скрипт (завязан на имя пускача), решаюший проблемы:
А) Kernel из библиотеки не может сам получить комстроку, берёт комстроку из переменной окружения.
Б) Надо добавить прописывание пути экзешника как пути поиска библиотеки, как Вы сами предложили.

Чего не хватает до полного описания Вашей схемы?

Всего хватает, я в сообщении выше подробнее расписал пункт Б:
  • LD_LIBRARY_PATH использовать не надо, по-нормальному libBB.so нужно устанавливать в ${PREFIX}/lib;
  • скрипт для запуска должен находиться в каталоге BlackBox. На него должна быть ссылка из ${PREFIX}/bin. Для того, чтобы правильно определялся путь к исполняемому файлу, нужно указывать его в скрипте так, как написано выше (через readlink -f ...).

Автор:  Евгений Темиргалеев [ Пятница, 28 Сентябрь, 2012 08:21 ]
Заголовок сообщения:  Re: Linux Console: структура папок, хранение материалов

Alexander Shiryaev писал(а):
Всего хватает, я в сообщении выше подробнее расписал пункт Б:
  • LD_LIBRARY_PATH использовать не надо, по-нормальному libBB.so нужно устанавливать в ${PREFIX}/lib;
  • скрипт для запуска должен находиться в каталоге BlackBox. На него должна быть ссылка из ${PREFIX}/bin. Для того, чтобы правильно определялся путь к исполняемому файлу, нужно указывать его в скрипте так, как написано выше (через readlink -f ...).
Например, у меня собрано несколько ББ:
Код:
 ~/
  bb1/
    BlackBox
    BlackBox.so
    BlackBox.sh
  bb2/
    BlackBox
    BlackBox.so
    BlackBox.sh
  bb3/
    BlackBox1
    BlackBox1.so
    BlackBox1.sh
    BlackBox2
    BlackBox2.so
    BlackBox2.sh
Будет так работать?

Сборка ББ должна быть в одной папке. Прежде всего должна поддерживаться эта стандартная простая схема: скопировал в любую папку и запустил.

Автор:  Alexander Shiryaev [ Пятница, 28 Сентябрь, 2012 08:43 ]
Заголовок сообщения:  Re: Linux Console: структура папок, хранение материалов

Евгений Темиргалеев писал(а):
Alexander Shiryaev писал(а):
Всего хватает, я в сообщении выше подробнее расписал пункт Б:
  • LD_LIBRARY_PATH использовать не надо, по-нормальному libBB.so нужно устанавливать в ${PREFIX}/lib;
  • скрипт для запуска должен находиться в каталоге BlackBox. На него должна быть ссылка из ${PREFIX}/bin. Для того, чтобы правильно определялся путь к исполняемому файлу, нужно указывать его в скрипте так, как написано выше (через readlink -f ...).
Например, у меня собрано несколько ББ:
Код:
 ~/
  bb1/
    BlackBox
    BlackBox.so
    BlackBox.sh
  bb2/
    BlackBox
    BlackBox.so
    BlackBox.sh
  bb3/
    BlackBox1
    BlackBox1.so
    BlackBox1.sh
    BlackBox2
    BlackBox2.so
    BlackBox2.sh
Будет так работать?

Сборка ББ должна быть в одной папке. Прежде всего должна поддерживаться эта стандартная простая схема: скопировал в любую папку и запустил.

Да

Страница 1 из 3 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/