OberonCore

Ну, 1.6 зато юникодная, как и линукс, кажись.

Репозиторий есть, https://svn.oberoncore.ru/community только он закрытый, доступ только по паролю, пароль у администратора, т.е. у Бориса Рюмшина

Дмитрий, уверен молчание вызвано не тем, что портирование нужно только Вам одному. Да Вы и без меня это прекрасно знаете. Рассматривали ли Вы мое предложение? Можно в личку.
P.S. В моей системе модуль Hello не запустился.

Про предложение этот пост?
Если так, то отвечу.

В различных вариантах динамической библиотеки необходимости нет. Есть необходимость сделать загрузчик, который запускал бы операционную среду, т.е. грузил бы часть модулей сразу, а потом остальные уже динамически.
На текущий момент это реализуется посредством создания libBB.so файла, загружающего модуль Kernel, который затем производит раскрутку.
Возможно, в дальнейшем можно будет доработать DevElfLinker с тем, чтобы формировались самостоятельно запускаемые файлы, без необходимости в дополнительной заглушки в виде файла BlackBox, получаемого из исходника BlackBox.c

2 Димыч
Было бы замечательно, если бы Вы нашли возможность использовать менее неожиданный архиватор.
Не знаю как в SuSe, а в репозитории RedHat rar(unrar) отсутствует.

С этим можно согласиться. Но чтобы Вы не теряли времени скажу: на официальном сайте архиватора есть бинарники под Линукс.

Тогда спрошу по-другому: что заставляет думать, что она ещё не переведёна? Понятно, что модули для работы с COM не заработают, но они в Линуксе и не нужны.

Стоп-стоп, компилятор не требует модификаций для Линукса. Модули двоично совместимы.

У меня запустилась сборка под номером два (в Mandriva Linux 2008). Может, уже имеет смысл выложить сборку в репозиторий и обрисовать какой-никакой план дальнейших действий по развитию, для желающих присоединиться.

Этот ответ Кушниру. Предложение было в первом моем посте здесь. Хотелось бы знать что Вы о нем думаете.

Все верно, компилятор в чистом виде не требует модификации.
Однако, та часть фреймворка, с которой он взаимодействует, в частности (на чем я споткнулся) StdLog, который, в свою очередь, использует HostDialog, требует переделки под Linux.
Кроме того, мне так и не удалось придумать, как подменить Kernel и не пересобирать всю остальную систему. Замена секций импорта оказалась самой надежной, хотя и довольно кропотливой возможностью для запуска ББ под Linux. Что приводит к полной пересборке всех подряд модулей, которые так или иначе задействованы.

Судя по цепочке вызовов, в вашей системе libdl.so и/или libc.so имеют нумерацию, отличную от моих. Посмотрите наличие указанных файлов с суффиксами, какие версии установлены? Если это предположение верно, то в заголовках модулей LinDL и LinLibc надо указать точный номер библиотеки, например, libdl.so.3 и пересобрать libBB.so.

В номерах разницы нет. С тем почему не запускалось разобрался. Дело как раз в упомянутом флаге PROT_EXEC. После его установки заработал Hello. Вот что strace выдает.

Дмитрий, попробуйте запустить ББ c параметром командной строки /USE


Тогда ББ будет компилировать изменённые исходники в тот каталог, который вы укажете, не затрагивая кодовые файлы в системном каталоге ББ. (если я правильно понял механизм работы)

Лучше всего слинковать всё необходимое. Примерно так

Теперь можно править что угодно.

Есть ещё один спрособ: использовать специальный загрузчик.


А вот это совсем непросто.

и
В итоге я использовал оба способа.
Завел две папки, HOST и TARGET, в каждой по инсталляции ББ. В папке HOST слинковал монолитный exe, который затем использовал для запуска с параметром /USE TARGET. В TARGET собирается целевая система, без какого-либо переименования модулей. Удобно. Спасибо за подсказки.

С момента, как я озадачился переводом ББ на Linux можно подвести первые итоги .

1) Эта работа осуществима.

Получен код, способный запускаться в Linux-среде. Пускай процедура запуска двухходовая (заглушка+libBB.so), однако она работающая.

2) По подсказке товарищей сделан механизм, позволяющий обеспечить кросскомпиляцию ББ практически без правок исходного кода. Суть метода в том, что есть две инсталляции ББ, одна из которых является компилирующей, а другая - собираемой. Компилирующая использует монолитный exe, которому не нужны сторонние библиотеки, а собираемая используется для сборки libBB.so и содержит другой kernel.

3) Попытка "сбороть" компилятор и раскрутить подсистему Dev на Linux не удалась.

Мне не удалось запустить компиляцию без графической среды, т.е. без использования подсистемы Text. Если есть возможность откомпилировать модуль строго по имени в строке (что-то вроде DevCompile???("module"), подскажите).

4) Для изготовления оконного интерфейса ББ на Linux можно взять X Window.

Тому есть несколько причин - есть готовые заголовочные файлы (после некоторой доводки запущена оконная программа); она не сложнее WinAPI, на котором сделан ББ для Windows; она работает весьма и весьма стабильно.

5) Под Linux заработали как ББ 1.5, так и ББ 1.6.

6) Несмотря на кросскомпиляцию, сборку лучше выкладывать в родном для Linux формате (*.zip) (первые архивы были в *.rar).

7) Необходимо подробно рассмотреть вопрос использования механизмов защиты памяти в Linux. На некоторых системах ББ просто не стартует, если не указать в коде флаг PROT_EXEC для функции mmap.

Продублировано отсюда

Разработкой, следует понимать, будете заниматься только вы один?

OpenBugs не оно, разве? Механизм скриптов можно взять.

Нет, конечно. С администрацией Oberoncore договорились сделать пространство на SVN, сейчас решается как это будет выглядеть. Одному мне это будет тяжко, хотя и подъемно.


Похоже, что нет. Как я понял, они схитрили. Там есть модуль Console, который умеет общаться с Linux-консолью. Так вот при запуске ББ просто уходит в цикл read-execute-write, внутри которого, собственно, уже ничего в ББ не меняется. Работает готовый код.
Компиляцию они делали на Windows.