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

[aBoomest]

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

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

[scifi]

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

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

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

[andrew_b]

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

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

[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, хотя они и не будут меняться.

[AVI-crak]

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

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

[scifi]

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

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