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

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

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

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



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

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

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

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

Спасибо.

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

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

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

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

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

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

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

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

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

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




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

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

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

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

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

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

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



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

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

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

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

Как то так.

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

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