OberonCore

Записал дельту KernelCmdline с тестом.
1) Если путь библиотечный не ставить, пуск не происходит.
2) Кавычки этот метод сжирает. Т.е. имена папок с пробелами не прокатят. Сие есть косяк т.к. расходится с поведением виндовой версии (там пользователи любят пробелы в именах папок). Можно как-то исправить?
---
В этом самая трабла по передаче ком. строки напрямую и заключается: argc и argv --- разобранные из комстроки аргументы. Даже если как-то заставить интерпретатор её не трогать и один в один передать, разобрать её изнутри ББ корректно не возможно, т.к. внешние правила разбора не известны. Корректный метод на мой взгляд только один: использовать даденые argc и argv, а не передавать комстроку, чтобы её компоненты, каким нужны параметры, парсили. Вроде уже про это писал.

Александр, что скажете насчёт "libBB.so: cannot open shared object file: No such file or directory"?

Скрипт, exe и .so лежат в одном каталоге (и только в нём, никаких ссылок нет и не планируется). В упор не понимаю, как система может найти .so там, если каталог не прописать в путях поиска.

Если хотите использовать libBB.so, находящуюся в том же каталоге, что и скрипт для запуска и исполняемый файл, а не в ${PREFIX}/lib, то надо запускать с установленной переменной окружения LD_LIBRARY_PATH. Тогда скрипт должен быть таким:

Спасибо, наконец-то всё стало по местам.

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

Положил в Dev/Docu/ElfLinker-Link как дополнительную документацию к DevElfLinker. Есть другие предложения?

Александр, если хотите, можете дополнить в конце насчет "Ваших" ОС-специфичных {$PREFIX}

${PREFIX} -- это аналог %PROGRAMFILES%, т. е. каталог, куда устанавливаются программы, которые могут быть доступны всем пользователям операционной системы.

Обычно это /usr, /opt или /usr/local в Linux и /usr/local в OpenBSD/FreeBSD. Исполняемые файлы обычно устанавливаются в ${PREFIX}/bin, библиотеки -- в ${PREFIX}/lib, документация -- в ${PREFIX}/share/doc, примеры -- в ${PREFIX}/share/examples, страницы man -- в ${PREFIX}/share/man.

Но могут быть исключения -- программы могут быть целиком установлены в ${PREFIX} (например, Java -- в ${PREFIX}/jdk-1.7.0, Adobe Acrobat -- в ${PREFIX}/Acrobat7) -- обычно это касается программ с собственной структурой каталогов. BlackBox как раз является одной из таких программ.

BlackBox должен быть установлен в ${PREFIX}/BlackBox, только libBB.so должна находиться в ${PREFIX}/lib (чтобы не занимать переменную LD_LIBRARY_PATH), а не в ${PREFIX}/BlackBox, и должна быть ссылка на запускающий скрипт в ${PREFIX}/bin (${PREFIX}/bin/blackbox -> ${PREFIX}/BlackBox/run-blackbox.sh).

У пользователей могут быть один или несколько рабочих каталогов BlackBox, которые могут задействоваться опцией /USE. Например:

или так:

Гкхм. Интересно, для кого Вы это написали тут?

Для читающих эту тему.

А чё, мне нравитца, что и как написано

Ну и хорошо, значит не зря.

Разрабатывать в ББ под линух можно спокойно без этого. Тем более, что хранение всего в одной замкнутой, контролируемой папке --- очень хорошая особенность ББ-приложений. Поэтому считаю, что пусковой скрипт по-умолчанию должен содержать LD_LIB..._PATH, а зацитированную информацию --- описанием необязательного способа ОС-специфичной оптимизации. По мне --- кто знает, тот и так догадается чего сделать, по общим словам; кто не знает --- нечего мозг насиловать, в конце концов, для садомазо есть мануалы на эту тему.

Однако, если Вы считаете необходимым дополнить материал этой информацией или примерами на тему, не буду иметь ничего против, если Вы это сами и сделаете. Или в том же документе, или отдельно, тогда поставим ссылку (подробнее см...)

Это всё к тому, что если делать .rpm и .deb пакеты, и устанавливать BlackBox в систему (как в C:\Program Files\ в Windows), а не в домашний каталог, то надо делать так, как я написал выше.

Вопросов нет. Тоже об этом писал (viewtopic.php?p=75102#p75102)

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

Поэтому и считаю задачу второстепенной и необходимой только ради распространения ББ (viewtopic.php?p=75112#p75112, Прочее, 3), учитывающий специфику народных масс. (Привычный, стандартный, как у всех способ установки и т.п.)

viewtopic.php?p=75425#p75425
Борис пробовал вчера вечером на убунте 12. Выявилась следующая штука: статически связанная библиотека не грузится до тех пор, пока не задействуется. Т.е. если для "убунты 10" достаточно пустого main, то для 12 нужно делать в библиотеке пустую процедуру и вызывать её из main. Остальное вроде остаётся без изменений.

Сегодня попозже постараюсь внести поправку в документацию и примеры.

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

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

Результаты сборки пускача example у меня (ubuntu 10), без вызова
у Бориса (ubuntu 12), без вызова
у Бориса, с вызовом

Ага!

(Освежите в памяти назначение четырёх команд сборки DevLinker) Вопрос по формированию пакета стал такой: или (А) довольно поддержать только один основной способ запуска --- мини-exe с рантаймом и дин. загрузкой остальных модуей (классчи. ББ приложение DevLinker.Link), или нужно (Б) поддержать все (доп: статич. экзе DevLinker.LinkExe, статич. библиотека для не-ББ приложения DevLinker.LinkDll, библ. с дин. загрукой для не ББ-приложения DevLinker.LinkDynDll).

Вопрос вроде как более политический нежели практический: либо пакет суть консольный для оригинального ББ, либо, т. сказать, для урезанного оригинального.

1) Отрабатываемая сейчас схема (с упрощающей поправкой) хорошо вписывается только для (А), сохраняет схему передачи параметров через командную строку, как в ББ для Windows; реализуема естественным для Linux способом.
2) Отказаться от передачи параметров через командную строку (как в ББ для Windows) в пользу их передачи через переменные окружения. Это второй легальный для Линух-программ способ передачи параметров. (Б) поддерживается без проблем.

Если этих общих соображений для выбора достаточно, прошу высказаться. Либо мне придётся более подробно расписывать обе схемы.

P.S. У меня уже были не один раз мысли --- выложить как есть, указав на проблемы, и думать дальше. Но если схема запуска поменяется, тем паче для (1) возможности сузятся, это будет не совсем красиво. Пока воздержался (думание продолжается закрыто, может затянуться и на неделю и на две). А вы, товарищи, как думаете --- пара недель погоды не делает или лучше скорее выложить?

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

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

На каком ядре остановились? В репозитории сейчас что-за ядро оказалось в итоге в папке System/Mod/ ? Ядро Александра все-таки пока недоделанное? Давайте версию для BSD выложим попозже, а вот для линукса ведь ядро есть от OpenBUGS 322. Считаю надо с ним пока выложить все вразумительные наработки по Linux версии.