Board.KolibriOS.org

Serge
Статические для меня лично не удобны не тем, что их приходится ликовать при компиляции, а FASM это не кушает. Столкнулся этим при прикручивании OpenDialog к kpack - код под Tasm я переписал на Fasm, а вот со статической библиотекой упаковки LZMA облом. Была мысль "линковать" через опцию file, но как оказалось сама библиотека LIB имеет хитрую структуру и при линковке в Tasm значительно модернизируется. Все хитрости относительно LIB я узнал у diamond'a через мессенджер.

В общем при любом раскладе мне нужно получить используемый в Колибри MS COFF OBJ для работы с ним в Fasm и было бы здорово придумать и отладить универсальную и достаточной простую методику получения. Или в текущем яре есть возможность загружать не только MS COFF OBJ? Позиция по этому вопросу не принципиальная, лишь бы была возможность простого вызова из приложения.

Mario

Дохлый номер. В больших библиотеках тысячи файлов. Часто пишут так что одна функция - один файл и соответственно один *.obj. Не случайно компоновщики несколько сот килибайт занимают и памяти требуют много. Вообще идея использовать COFF.obj для длл была крайне неудачной. Надо было сразу делать PE. А все это дурацкое общее стремление сэкономить пару байт. Теперь оно выходит боком. С одной стороны DLL вроде и есть и даже расшарены, а с другой попробуй скомпилируй freetype, ffmpeg или mesa в один файл.

Serge
Но ведь есть утилиты которые собирают LIB из OBJ - неужели нельзя написать обратную процедуру, чтобы распотрошила LIB на кучу OBJ?

Mario

Те же самые утилиты и потрошат. Это ведь архив. ar -x имя_библиотеки. Извлекает все объекты. Только их там сотни и между ними прекрёстные ссылки. Один тянет за собой десяток других. Вот для примера список объектов в libavcodec.a

Serge
Т.е. линковщик эти самые перекрестные связи анализирует и оставляет только нужные?

Mario

Да. Строятся списки имён переменных и функций по всем объектным файлам и дерево зависимостей. Если на переменные и функции из объектного файла нет ссылок он не включается в конечную программу. Eщё проводится масса различных оптимизаций. Последние версии компоновщиков вообще сами генерируют окончательный код (Link-time code generation). Компилятор создаёт промежуточный псевдокод для программы и библиотечных функций из которого компоновщик собирает программу. Bochs после такой компиляции получается процентов на 20 меньше и заметно быстрее.

Serge
Вопрос тогда такой: те OBJ которые в LIB - они имеют формат подобный Колибри OBJ или отличаются, т.е. их нельзя загрузить и использовать в Колибри без переделки?

Если там MS COFF то формат файла совпадает. Но в библиотеке Колибри должна быть самодельная таблица экспорта и метка EXPORTS. Без неё импорт из библиотеки невозможен.

> мне нужно получить используемый в Колибри MS COFF OBJ
diamond же сделал утиль по конвертации DLL в OBJ, чуть ли не по моей просьбе (kex, без сорцев). Работает, я проверял. Костыль конечно, но лучше чем ничего.

..bw

DLL в OBJ это конечно замечательно, но мне в конкретном случае надо kpack доковырять с уже имеющейся LIB библиотекой.
Спасибо за сведения - в любом случае пригодится.

Serge wrote: Вообще идея использовать COFF.obj для длл была крайне неудачной. Надо было сразу делать PE.

Надеюсь к драйверам это отношения не имеет.

Asper wrote:

Serge wrote: Вообще идея использовать COFF.obj для длл была крайне неудачной. Надо было сразу делать PE.

Надеюсь к драйверам это отношения не имеет.

Ты не уловил сослогательного наклонения в истории альтернативной реальности?

Asper

Имеет. Новый драйверы в PE формате. Кстати ничто не мешает писать их и на ассемблере.

Но старые то ведь поддерживаются? Или неужто все переписал на PE?

Поддерживаются. Их и в PE пересобрать можно. Благо COFF.