Библиотеки Опции

[aBoomest]

Добрый день.
Делаю проект в IAR EW для ARM. Вопрос по библиотекам *.a.
Библиотеки в IAR EW - это бинарный исполняемый файл или нет?
Что я имею ввиду
Библиотеки в IAR EW - это бинарный исполняемый файл что-то типа *.dll
или
Библиотеки в IAR EW - это промежуточный бинарный файл который еще будет компилироваться - что-то типа *.lib в обычном С и С++ для х86.

Т.е. *.a - это непосредственно готовый файл который может выполняться на процессоре?

[novikovfb]

Обычно *.a - архив объектных модулей (объектная библиотека), нужен для сборки программы линкером.

[Forger]

В IAR решили выпендрится перед всеми другими средами и называли *.lib по-своему - "*.a".

Библиотеки в IAR EW - это промежуточный бинарный файл который еще будет компилироваться - что-то типа *.lib в обычном С и С++ для х86.

"*.lib" файл невозможно скомпилировать повторно, он УЖЕ скомпилирован. Равно как и "*.a" в IAR
Их потом "скармливают" линкеру/компоновщику, на его выходе получают HEX/BIN/AXF и т.п. файлы, которые уже можно шить в проц.

[scifi]

Библиотеки в IAR EW - это бинарный исполняемый файл что-то типа *.dll

Т.е. *.a - это непосредственно готовый файл который может выполняться на процессоре?

Вы, наверное, не в курсе. DLL не выполняется на процессоре. Он загружается в память загрузчиком, и загрузчик делает так, что загруженный код может выполняться на процессоре.
Не исключено, что для библиотечных файлов можно сделать похожий загрузчик, то есть загружать и компоновать код не статически, а динамически. Но зачем?

[AlexandrY]

Т.е. *.a - это непосредственно готовый файл который может выполняться на процессоре?

*.a - это контейнер для кучи elf файлов. elf файлы могут иметь разную форму.
Они могут быть зависимы от позиции и тогда перед запуском их надо модифицировать и могут быть независимы и тогда их можно запускать сразу.
Конвертацию elf файлов делает либо линкер либо загрузчик на целевой платформе.
Т.е. заранее однозначно сказать нельзя нужно или не нужно что-то делать с содержимым elf файла. Вернее нужно посмотреть заголовки этих файлов на предмет зависимостей.
Сам формат *.a конечно всегда нужно парсить чтобы выделить в нем непосредственно область кода.

[andrew_b]

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

Why and how are some shared libraries runnable, as though they are executables?

[aBoomest]

Спасибо.

[AVI-crak]

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

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

Посему - брось эту каку, и больше не наступай - измажься весь, и от запаха уже не избавишься.

[Forger]

...брось эту каку, и больше не наступай - измажься весь, и от запаха уже не избавишься.

Не стоит так все драматизировать!
lib/a файлы - вполне годное и полезное решение, например, чтобы избежать пересборки толстого проекта при каждом ребилде.

Например, в свое время я наделал таких lib из кучи c-файлов их периферийноф библиотеки SPL от ST. Потом просто добавлял соотв. либу в дерево файлов.
Сборка такого проекта проходит всегда быстрее.

А в очень больших проектах уже отлаженные модули самого проекта тоже собирал в соотв. либы и подключал их к финальной сборке.
Так и отлаживать проще (по частям) и вообще удобнее.
Если среда поддерживает такое понятие, как Project Workspace, то это cделать очень просто.

Короче, в сторонние либах ничего плохого нет. © "Не так страшен черт, как его молюют"
Более того в любом даже убогом проекте линкер и так подключит автоматом свои библиотеки, идущую в комплекте с компилятором (хотя от и можно отказаться, чем нажить себе доп. головную боль).
Поэтому - все на либах/все спрятать от гипотетических воров - и наоборот - никаких lib, голые сырцы - это две крайности и обе одинаково вредны.
Разумно - искать компромисс

[AVI-crak]

Не стоит так все драматизировать!
lib/a файлы - вполне годное и полезное решение, например, чтобы избежать пересборки толстого проекта при каждом ребилде.

Это имеет смысл когда к библиотеке есть документация, полный набор файлов для быстрого поиска функций, или когда библиотека твоя личная. Но вот использовать жирную чужую библиотеку без возможности заглянуть в её содержимое - уже явный перебор.
Кстати насчёт пересборки проекта - gcc следит за изменениями в файлах, если кеш *.a разрешен - то он его не собирает каждый раз, а использует уже имеющиеся. Это работает даже при переключении проектов. Файлы *.a остаются в папке сборки, и используются по мере надобности. Устаревшая версия уничтожается автоматически.
Так-что насчёт жирных проектов - не всё столь однозначно.

[Forger]

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

А как можно пользоваться библиотекой, если к ней нет документации (на край вменяемо написанных h-файлов)? Наугад тыкаться?

Где такую можно скачать?

Кстати насчёт пересборки проекта - gcc следит за изменениями в файлах,

Это умеет делать любой компилятор. С этим спора нет.
Но при условии, если не было изменений в файлах, которые инклудятся в соотв. c/c++ файлах.
Поэтому помимо простой сборки проекта существует еще отдельная возможность принудительной пересборки проекта, что-то типа "REBUILD".
В т.ч. CLEAN - удалить все эти скомпилированные *.obj файлы, после которой по-любому весь проект будет компилироваться заново и полностью.

По мне проще и удобнее подключить к проекту несколько соотв. lib-файлов с соотв. интерфейсными h-файлами, вместо груды исходников, которые потом придется "тащить" через весь проект, вынужденно добавляя их в SVN, хотя они и не будут меняться.

[scifi]

По мне проще и удобнее подключить к проекту несколько соотв. lib-файлов с соотв. интерфейсными h-файлами, вместо груды исходников, которые потом придется "тащить" через весь проект, вынужденно добавляя их в SVN, хотя они и не будут меняться.

Вот мы и добрались до сути. На самом деле в SVN есть такая штука, как externals. Она позволяет добавить к рабочей копии проекта ту самую "груду исходников" (библиотечный код) из немного другого места, причём с определённой ревизией. Это более прогрессивный подход, так как позволяет подключить к проекту нужную версию библиотечного кода. При изменениях в библиотечном коде (исправление ошибок, например), зависящие от него проекты не изменятся. В то же время есть возможность подтянуть туда эти изменения, всего лишь изменив номер ревизии в externals.
.lib тут ни при чём, это второстепенная деталь.

[Forger]

Вот мы и добрались до сути. На самом деле в SVN есть такая штука, как externals.

Так далеко в SVN я еще не забирался .....
Фактически у меня сейчас так и сделано, но не на базе SVN, а просто - проекты лежат в одном месте, а общие библиотеки в другом месте, но рядом.
Если пересобираю общие библиотеки, то зависимые проекты тоже нужно пересобирать.
Т.е. все это делаю можно сказать "вручную".
Если SVN это все упрощает и автоматизирует, то это - очень полезно!
Короче, спасибо за подсказку !

.lib тут ни при чём, это второстепенная деталь.

Одно другому не мешает - все это, имхо, дело вкуса и личных предпочтений

[zhevak]

В IAR решили выпендрится перед всеми другими средами и называли *.lib по-своему - "*.a".

Вообще-то в мире есть лагерь Виндовс и есть лагерь UNIX/Linux. В каждом лагере приняты свои гласные и негласные правила. В том числе и правила именования файлов.

Вот небольшая табличка соответствия суффикосов имён файлов в Линуксе расширениям имен в Виндовсе.

Код

                                 UNIX/Linux   Windows
                                 ----------   --------
Объектный модуль:                File.o       FILE.OBJ
Статическая библиотека (архив):  statLib.a    LIBA.LIB
Динамическая библиотека:         dynLib.so    DYNLIB.DLL
Программа:                       Proga        PROGA.EXE

Мне думакется, что в компании IAR тупо взяли за основу gcc (который произростает из UNIX/Linux) и не захотели переделывать его на платформу Виндовса.

Кроме того, в Линуксе принято к началу имени статической библиотеки добавлять три буквы -- "lib". Например, математическая библиотека имеет имя "libm.a".

В Линуксе вообще понятие "расширение имени файла" ничем не поддерживается. Всё, что есть, -- это всё есть имя файла. И никаких расширений.
Любовь придумали мужчины, чтобы не платить... Расширения придуманы в Виндовсе.

Поэтому, в именах программ нет никаких дополнительных элементов, а символ точка (".") в имени файла -- это точно такой же символ как и другие
Вас же не удивляет, что родительский каталог имеет имя состоящее из двух точек (".."). К стати, имя текущиго каталога -- это одна точка (".").
Более того, в Линуксе файлы, чьи имена начинаются с точки, считаются скрытыми. Поэтому текущий и родительский дириктории -- сходу являются скрытыми.
С точки зрения пользователя Виндовса это всё необычно и кажется уродливым. Но с точки зрения пользователя UNIX/Linux -- это вполне нормальные
комфортные правила. Каждому своё. В мире много языков (русский, китайский, английский). У каждого языка свои достоинства и свои проблемы.
Просто, это -- разные миры. Но в каждом мире свои правила.

Как то так.

Не надо "катить" на IAR. Пионист играет, как умеет.

[AVI-crak]

А как можно пользоваться библиотекой, если к ней нет документации (на край вменяемо написанных h-файлов)? Наугад тыкаться?

Ви таки не поверите, почти все собранные библиотеки имеют политику частичного объявления. Это связанно с тем что они имеют внутренние, не публичные функции, предназначенные для собственной корректной работы.

[scifi]

Ви таки не поверите, почти все собранные библиотеки имеют политику частичного объявления. Это связанно с тем что они имеют внутренние, не публичные функции, предназначенные для собственной корректной работы.

Это всё ересь. Должна быть возможность быстро подготовить машину для сборки (установить на неё ось, тулчейн, утилиты для сборки). Потом svn checkout, make. Всё. Остальное - от лукавого.

[Forger]

Ви таки не поверите, почти все собранные библиотеки имеют политику частичного объявления. Это связанно с тем что они имеют внутренние, не публичные функции, предназначенные для собственной корректной работы.

Это и так понятно: пользователю библиотеки к соотв. либ-файлу будет прилагаться "упрощенные" h.файлы, с минимально необходимыми объявлениями, лишь для того, чтобы использовать библиотеку.
Но к этим h-файлам необходима еще и документация: описания функций, возвращаемые ими значения, примеры применения и т.п.
Без всего этого ЛЮБАЯ библиотека - просто мусор.

Пионист играет, как умеет.

Спасибо за такой основательный ликбез! Весьма познавательно! Я серьезно.

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