Библиотеки-модули-программы...

[elf/2]

Если на Амиге есть релокация, то почему нету динамической компоновки, а вместо неё "загрузчики" и "пост-компиляторы"?

ты о чем? с самого начала acidrain говорил о динамической компоновке и привел кучу примеров. в терминах MSDN на амми есть "run-time dynamic linking"

[Vitamin]

маленький такой комментарий, объектные файлы с платформой вообще не связаны, это "фича" среды разработки (компилятор+линкер)

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

[elf/2]

2. не могу представить как дос либрари потребуется графикс либрари. дело в том, что это не модули, а либрари, но называй их как угодно. как и прога, обмен через messages, signals, stack. только зачем?

витамин спрашивал можно ли хранить внутри библиотеки ресурсы: иконки, строки и т.д
ну и есть ли унифицированный способ их оттуда достать.

зачем это надо? пара примеров:
1. несколько программ используют одинаковую иконку "open file".
2. хотим программу с локализованным интерфейсом. делаем библиотеку которая хранит только тексты сообщений. соответсвенно будет иметь несколько ресурсных библиотек по одной для каждого языка

есть ли на амми стандартный механизм для "шаринга" ресурсов? (это не наезд, а вопрос)

[GriV]

А когда одна версия C, можно ли если граф импорта имеет склеенные ветки, собрать результат с одним экземпляром C?
А, Vitamin?

Я тут хорошо подумал, попытаюсь иначе изложить, витамин кстати сам согласен что так можно, теоретически - практически этого нет, но тем не менее

Смысл такой - пусть имеет куча модулей - А и Б
причём модуль А имеет набор публичных вызовов
public OneFunc
public TwoFunc
public ThreeFunc
Модуль Б имеет публичные вызовы
public OneFunc
public TwoFunc
public FourFunc

Приложению П которое для сборки использует А и Б надо пользоваться функциями public ThreeFunc и public FourFunc (это общие функции). Казалось бы - модули используют конфликтные имена функций, но П не использует эти функции, поэтому сборка возможна, а функции
public OneFunc
public TwoFunc
для А и функции
public OneFunc
public TwoFunc
для Б
станут контекстно-приватными (т.е. в общем то публичными, но вследствие их ненужности для П их можно сделать внутренними для модулей).
В итоге склейка произойдёт на ура и всё будет работать.

А как это связано с тем что А и Б могут использовать разные библиотеки - С1.0 и С2.0? - да очень просто. При склейке А с С1.0 и Б с С2.0 получатся A+C1.0 и Б+С2.0, причём более библиотека С не нужна (ни одна из версий). Подчеркиваю важность момента - приложение П напрямую не пользуется ни одной версией C (в этом случае опять придётся склеивать П с С и получив например П+C3.0 вязать их с А+С1.0 и Б+С2.0).
Далее, для А и Б будет список повторяющихся методов, которые тем не менее не используются в П. Тогда можно запросто сделать эти методы контекстно-приватными и работать с библиотеками без конфликтов по тем методам, которые являются контекстно-публичными.

[elf/2]

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

понимать можно что угодно под чем угодно но так уж получилось, что объектный файл это устоявшийся термин (по крайней мере для писюканцев ). по крайней мере я всегда считал что объектник это результат работы компилятора (в формате REL, OMF, whatever) который даже теоретически исполнить нельзя поскольку внешние ссылки еще не разрешены. из набора этих полуфабрикатов линкер (ln, link, иногда сам компилятор) собирает исполняемый бинарик/динамическую библиотеку

[Vitamin]

который даже теоретически исполнить нельзя поскольку внешние ссылки еще не разрешены. из набора этих полуфабрикатов линкер (ln, link, иногда сам компилятор) собирает исполняемый бинарик/динамическую библиотеку

Результатом работы gcc без параметров является файл a.out, который тут же можно запустить. Добавить ключик- получим динамическую библиотеку, другой ключик- статическую, третий- объектный файл

[elf/2]

Результатом работы gcc без параметров является файл a.out, который тут же можно запустить. Добавить ключик- получим динамическую библиотеку, другой ключик- статическую, третий- объектный файл

Витамин, ты издеваешься? ладно давай от печки... любая разумная программа имеет зависимость как минимум от run-time библиотеки (libc на линуксе, msvcrt на винде). поскольку современные компиляторы "думают" о пользователе они позволяют позвать линкер автоматом. т.е. прога комилиться в объектник (я думаю если постараться то можно заметить что файл .o создается в текущем каталоге) и махом зовется линкер для того чтобы слинковаться с рантаймом. аналогично с динамической библиотекой (только run-time будет другой). а статическая библиотека это просто набор упакованных объектников

[Vitamin]

Витамин, ты издеваешься?

Не, к словам придираюсь ))

Я протупил слегка с терминологией. Хотя имел в виду именно объектный файл как болванка для создания исполнимого приложения. И на каждой платформе он будет в общем случае своим изза архитектурных различий.

[elf/2]

И на каждой платформе он будет в общем случае своим изза архитектурных различий.

скажу больше, для двух разных приложений эти файлы тоже будут отличаться

еще раз, формат объектного файла зависит от компилятора. например компиляторы borland и ms для виндовс используют разные расширения формата.

[Vitamin]

скажу больше, для двух разных приложений эти файлы тоже будут отличаться
еще раз, формат объектного файла зависит от компилятора. например компиляторы borland и ms для виндовс используют разные расширения формата.

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