[aBoomest 0]

Добрый день.

Делаю проект в IAR EW для ARM. Вопрос по библиотекам *.a.

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

Что я имею ввиду

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

или

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

 

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

[novikovfb 17]

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

 

[Forger 17]

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

 

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

 

"*.lib" файл невозможно скомпилировать повторно, он УЖЕ скомпилирован. Равно как и "*.a" в IAR

Их потом "скармливают" линкеру/компоновщику, на его выходе получают HEX/BIN/AXF и т.п. файлы, которые уже можно шить в проц.

[scifi 1]

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

 

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

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

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

[AlexandrY 2]

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

 

*.a - это контейнер для кучи elf файлов. elf файлы могут иметь разную форму.

Они могут быть зависимы от позиции и тогда перед запуском их надо модифицировать и могут быть независимы и тогда их можно запускать сразу.

Конвертацию elf файлов делает либо линкер либо загрузчик на целевой платформе.

Т.е. заранее однозначно сказать нельзя нужно или не нужно что-то делать с содержимым elf файла. Вернее нужно посмотреть заголовки этих файлов на предмет зависимостей.

Сам формат *.a конечно всегда нужно парсить чтобы выделить в нем непосредственно область кода.

[andrew_b 14]

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

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

[aBoomest 0]

Спасибо.

[AVI-crak 0]

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

 

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

 

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

[Forger 17]

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

Не стоит так все драматизировать! :laughing:

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

 

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

Сборка такого проекта проходит всегда быстрее.

 

А в очень больших проектах уже отлаженные модули самого проекта тоже собирал в соотв. либы и подключал их к финальной сборке.

Так и отлаживать проще (по частям) и вообще удобнее.

Если среда поддерживает такое понятие, как Project Workspace, то это cделать очень просто.

 

Короче, в сторонние либах ничего плохого нет. © "Не так страшен черт, как его молюют"

Более того в любом даже убогом проекте линкер и так подключит автоматом свои библиотеки, идущую в комплекте с компилятором (хотя от и можно отказаться, чем нажить себе доп. головную боль).

Поэтому - все на либах/все спрятать от гипотетических воров - и наоборот - никаких lib, голые сырцы - это две крайности и обе одинаково вредны.

Разумно - искать компромисс ;)

[AVI-crak 0]

Не стоит так все драматизировать! :laughing:

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

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

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

Так-что насчёт жирных проектов - не всё столь однозначно.

[Forger 17]

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

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

 

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

 

 

 

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

Это умеет делать любой компилятор. С этим спора нет.

Но при условии, если не было изменений в файлах, которые инклудятся в соотв. c/c++ файлах.

Поэтому помимо простой сборки проекта существует еще отдельная возможность принудительной пересборки проекта, что-то типа "REBUILD".

В т.ч. CLEAN - удалить все эти скомпилированные *.obj файлы, после которой по-любому весь проект будет компилироваться заново и полностью.

 

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

[scifi 1]

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

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

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

[Forger 17]

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

Так далеко в SVN я еще не забирался .....

Фактически у меня сейчас так и сделано, но не на базе SVN, а просто - проекты лежат в одном месте, а общие библиотеки в другом месте, но рядом.

Если пересобираю общие библиотеки, то зависимые проекты тоже нужно пересобирать.

Т.е. все это делаю можно сказать "вручную".

Если SVN это все упрощает и автоматизирует, то это - очень полезно!

Короче, спасибо за подсказку !

 

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

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

[zhevak 0]

В 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 0]

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

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