OberonCore

Привет!

Не получается слинковать (получить exe) для тестовой программы. Точнее получается до тех пор, пока дело не доходит до Kernel.

DevLinker.Link
MyBlackBox.exe := Kernel$+ MyTest

National not present (imported in Kernel)

Дело в том, что в примере в документации не учитывается, что при русификации Горячевым был введен модуль National, который действительно импортируется ядром (раньше Kernel не зависел ни от чего). Поэтому в список для линковки нужно включить National.

Вот как пересобирал я:
Autorg.exe := National Kernel$+ Files HostFiles StdLoader
1 Autorg.ico 2 Doclogo.ico 3 SFLogo.ico 4 CFLogo.ico 5 DtyLogo.ico
1 Move.cur 2 Copy.cur 3 Link.cur 4 Pick.cur 5 Stop.cur 6 Hand.cur 7 Table.cur

Менял только иконку приложения.

Я тоже так подумал и попробовал явно включить этот модуль в список. Только это не помогло. Оказывается имеет значение порядок, в котором указаны модули - у меня сначала шел Kernel, a потом National. В чем глубокий смысл такого ограничения?

Порядок записи - порядок импорта модулей друг другом. Kernel импортирует National.

Я это уже понял Вопрос - зачем?

Ну как зачем? Линковщик может, конечно, просчитать это сам. Но здесь немножко по-другому. Просто список можно сгенерить автоматически. Либо на основе загруженных модулей, либо на основе того, что необходимо для какого-то конкретного модуля. DevDependencies, кажется. Могу ошибаться... Где-то в документации Dev описано.

Т.е., это можно считать банальной недоработкой линковщика (с точки зрения удобства использования) и никакого глубокого смысла в этом нет?

Попробуйте без make собрать вручную ядро Линукса. Узнаете как линковщики работают... А потом поговорим о недоработках, в плане удобства...

Причем здесь линукс? Возможно при сборке его ядра для его линковщика этот порядок имеет какое-то значение (например, он влияет на порядок инициализации статических объектов). Меня интересует BB. Если порядок указания модулей ни на что не влияет (кроме факта успешной сборки), то это - недоработка.

Почему не влияет? Порядок сборки - это порядок, в котором выстраиваются зависимости между модулями. Да, его можно просчитать автоматически, и для этого есть отдельный инструмент. Почему не сразу?

Причины две:
1) Линковка - этап редкий при обычной разработке под ББ. В основном предполагается поставка отдельных динамически загружаемых модулей (как и .NET, собственно говоря).
2) Если уже решено линковать, то обычно могут быть два варианта:
а) линкуется небольшое число модулей при пересборке ББ или сборке своего системного приложения. Тогда выстроить связи - не только не проблема, но даже лишний раз повод проанализировать, что от чего зависит
б) линкуется вся среда. Тогда вручную все равно никто писать сотни файлов не будет. Список генерится либо из списка текущих загруженных модулей, либо перечислением файлов конкретных подсистем.

Не только. Это ещё и порядок инициализации. Иногда он бывает очень важен и его нельзя так просто вычислить по зависимостям.

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

Если мы будем брать только импортируемые модули, тогда (при грамотно спроектированном приложении) мы пропустим всю подсистему Host, например, которая жизненно необходима для работы (никто ведь не будет импортировать HostFiles, все пользуются Files).

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

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

Не понял чё-то я. Ведь сам Files импортирует HostFiles? Так в чём проблема? По-моему сформировать список достаточных для работы модулей - задача вполне решаемая.

Проблмема в том, что не импортирует .

Sacred, дело в том, что действительно не импортирует. Иначе бы получилась зависимость абстракного переносимого модуля Files от платформенно зависимого HostFiles. В Files (и в Ports, и др.) объявлены абстрактные файлы, порты, ... , для создания которых объявлены не менее асбтрактые фабрики Directory. А как клиент получает доступ к конкрентной фабрике? При загрузке среды и инициализации модули Host вызывают SetDirectory соответствующих абстрактных модулей, т.е. делают инсталляцию фабрики. А клиентские модули приходят уже "на готовенькое" и знают только, что текущая фабрика находится в переменной dir абстрактного модуля. Кстати, никто не мешает подменить фабрику прямо "на горячую". Предыдущая останется доступной через stdDir.

Ещё секрет DevLinker: чтобы собрать экзешник с признаком CUI ("врождённо-консольного" приложения), используется ключ dos:
DevLinker.Link dos MyApp.exe := ...

Илья, Ваш пример модуля, использующего glut, я успешно скомпоновал, но вот когда добавил в пример импорт ещё одного модуля и внёс его в список компонуемых модулей, то получил "failed". После чего осознал, что недопонимаю, по каким же принципам работает линковщик. Не осветите ли суть?:)

Условно говоря, у Вас было

и всё вышло ok.

А потом я сделал

и получил failed.

Скорее всего, Вы не указали те модули, которые требуются для NewModule, перед ним в команде:

Если так, смотрите внимательно лог (журнал). Там будет указано, что NewModule импортирует такие-то модули, а в списке (до него) их нету. Впишите.

У меня жесть полная...Со временем, пока я прописывал те модули, которые "not present", я получил следующий список...



Слинковав все вот это и запустив, я получил trap#100

Там идут жалобы из кёрнеля, стдлодыря и FormViews...

Когда я написал...



На меня пожаловались, мол illegal memory read [ad = FFFFFFFC], а дальше, чего там понаписано я писать не буду...

Я вообще не понял чего он от меня хочет...

Отсюда, следует логичный традиционный вопрос: "Что делать?"

Извините, но буду вынужден ответить не менее традиционным вопросом на традиционный вопрос. А что же Вам надо? (Задачу сформулируйте)