aBoomest 0 16 мая, 2018 Опубликовано 16 мая, 2018 · Жалоба Добрый день. Делаю проект в IAR EW для ARM. Вопрос по библиотекам *.a. Библиотеки в IAR EW - это бинарный исполняемый файл или нет? Что я имею ввиду Библиотеки в IAR EW - это бинарный исполняемый файл что-то типа *.dll или Библиотеки в IAR EW - это промежуточный бинарный файл который еще будет компилироваться - что-то типа *.lib в обычном С и С++ для х86. Т.е. *.a - это непосредственно готовый файл который может выполняться на процессоре? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
novikovfb 17 16 мая, 2018 Опубликовано 16 мая, 2018 · Жалоба Обычно *.a - архив объектных модулей (объектная библиотека), нужен для сборки программы линкером. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 19 16 мая, 2018 Опубликовано 16 мая, 2018 · Жалоба В IAR решили выпендрится перед всеми другими средами и называли *.lib по-своему - "*.a". Библиотеки в IAR EW - это промежуточный бинарный файл который еще будет компилироваться - что-то типа *.lib в обычном С и С++ для х86. "*.lib" файл невозможно скомпилировать повторно, он УЖЕ скомпилирован. Равно как и "*.a" в IAR Их потом "скармливают" линкеру/компоновщику, на его выходе получают HEX/BIN/AXF и т.п. файлы, которые уже можно шить в проц. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scifi 1 16 мая, 2018 Опубликовано 16 мая, 2018 · Жалоба Библиотеки в IAR EW - это бинарный исполняемый файл что-то типа *.dll Т.е. *.a - это непосредственно готовый файл который может выполняться на процессоре? Вы, наверное, не в курсе. DLL не выполняется на процессоре. Он загружается в память загрузчиком, и загрузчик делает так, что загруженный код может выполняться на процессоре. Не исключено, что для библиотечных файлов можно сделать похожий загрузчик, то есть загружать и компоновать код не статически, а динамически. Но зачем? :laughing: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 16 мая, 2018 Опубликовано 16 мая, 2018 · Жалоба Т.е. *.a - это непосредственно готовый файл который может выполняться на процессоре? *.a - это контейнер для кучи elf файлов. elf файлы могут иметь разную форму. Они могут быть зависимы от позиции и тогда перед запуском их надо модифицировать и могут быть независимы и тогда их можно запускать сразу. Конвертацию elf файлов делает либо линкер либо загрузчик на целевой платформе. Т.е. заранее однозначно сказать нельзя нужно или не нужно что-то делать с содержимым elf файла. Вернее нужно посмотреть заголовки этих файлов на предмет зависимостей. Сам формат *.a конечно всегда нужно парсить чтобы выделить в нем непосредственно область кода. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
andrew_b 15 16 мая, 2018 Опубликовано 16 мая, 2018 · Жалоба Не исключено, что для библиотечных файлов можно сделать похожий загрузчик, то есть загружать и компоновать код не статически, а динамически. Но зачем? :laughing: Why and how are some shared libraries runnable, as though they are executables? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aBoomest 0 16 мая, 2018 Опубликовано 16 мая, 2018 · Жалоба Спасибо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AVI-crak 0 16 мая, 2018 Опубликовано 16 мая, 2018 · Жалоба *.a готовое - часто используется для защиты интеллектуальной собственности. В том виде как есть - очень сложно заглянуть в сам контейнер. Имеющийся публичная декларация может быть не полной, с использованием множества перекрёстных ссылок в тени. В таком случае добавляя всего одну функцию из подобной библиотеки - получаешь весь табор цыган, которые и память сожрут, и коня уведут. Особым извращением считается переключение типа процессора в теле *.a библиотеки, ну потому-что нишмогла, а может и просто знаний не хватило, а может и очередной костыль чтоб работало везде... Посему - брось эту каку, и больше не наступай - измажься весь, и от запаха уже не избавишься. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 19 16 мая, 2018 Опубликовано 16 мая, 2018 · Жалоба ...брось эту каку, и больше не наступай - измажься весь, и от запаха уже не избавишься. Не стоит так все драматизировать! :laughing: lib/a файлы - вполне годное и полезное решение, например, чтобы избежать пересборки толстого проекта при каждом ребилде. Например, в свое время я наделал таких lib из кучи c-файлов их периферийноф библиотеки SPL от ST. Потом просто добавлял соотв. либу в дерево файлов. Сборка такого проекта проходит всегда быстрее. А в очень больших проектах уже отлаженные модули самого проекта тоже собирал в соотв. либы и подключал их к финальной сборке. Так и отлаживать проще (по частям) и вообще удобнее. Если среда поддерживает такое понятие, как Project Workspace, то это cделать очень просто. Короче, в сторонние либах ничего плохого нет. © "Не так страшен черт, как его молюют" Более того в любом даже убогом проекте линкер и так подключит автоматом свои библиотеки, идущую в комплекте с компилятором (хотя от и можно отказаться, чем нажить себе доп. головную боль). Поэтому - все на либах/все спрятать от гипотетических воров - и наоборот - никаких lib, голые сырцы - это две крайности и обе одинаково вредны. Разумно - искать компромисс ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AVI-crak 0 16 мая, 2018 Опубликовано 16 мая, 2018 · Жалоба Не стоит так все драматизировать! :laughing: lib/a файлы - вполне годное и полезное решение, например, чтобы избежать пересборки толстого проекта при каждом ребилде. Это имеет смысл когда к библиотеке есть документация, полный набор файлов для быстрого поиска функций, или когда библиотека твоя личная. Но вот использовать жирную чужую библиотеку без возможности заглянуть в её содержимое - уже явный перебор. Кстати насчёт пересборки проекта - gcc следит за изменениями в файлах, если кеш *.a разрешен - то он его не собирает каждый раз, а использует уже имеющиеся. Это работает даже при переключении проектов. Файлы *.a остаются в папке сборки, и используются по мере надобности. Устаревшая версия уничтожается автоматически. Так-что насчёт жирных проектов - не всё столь однозначно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 19 16 мая, 2018 Опубликовано 16 мая, 2018 · Жалоба Это имеет смысл когда к библиотеке есть документация, полный набор файлов для быстрого поиска функций, или когда библиотека твоя личная. Но вот использовать жирную чужую библиотеку без возможности заглянуть в её содержимое - уже явный перебор. А как можно пользоваться библиотекой, если к ней нет документации (на край вменяемо написанных h-файлов)? Наугад тыкаться? :smile3046: Где такую можно скачать? Кстати насчёт пересборки проекта - gcc следит за изменениями в файлах, Это умеет делать любой компилятор. С этим спора нет. Но при условии, если не было изменений в файлах, которые инклудятся в соотв. c/c++ файлах. Поэтому помимо простой сборки проекта существует еще отдельная возможность принудительной пересборки проекта, что-то типа "REBUILD". В т.ч. CLEAN - удалить все эти скомпилированные *.obj файлы, после которой по-любому весь проект будет компилироваться заново и полностью. По мне проще и удобнее подключить к проекту несколько соотв. lib-файлов с соотв. интерфейсными h-файлами, вместо груды исходников, которые потом придется "тащить" через весь проект, вынужденно добавляя их в SVN, хотя они и не будут меняться. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scifi 1 16 мая, 2018 Опубликовано 16 мая, 2018 · Жалоба По мне проще и удобнее подключить к проекту несколько соотв. lib-файлов с соотв. интерфейсными h-файлами, вместо груды исходников, которые потом придется "тащить" через весь проект, вынужденно добавляя их в SVN, хотя они и не будут меняться. Вот мы и добрались до сути. На самом деле в SVN есть такая штука, как externals. Она позволяет добавить к рабочей копии проекта ту самую "груду исходников" (библиотечный код) из немного другого места, причём с определённой ревизией. Это более прогрессивный подход, так как позволяет подключить к проекту нужную версию библиотечного кода. При изменениях в библиотечном коде (исправление ошибок, например), зависящие от него проекты не изменятся. В то же время есть возможность подтянуть туда эти изменения, всего лишь изменив номер ревизии в externals. .lib тут ни при чём, это второстепенная деталь. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 19 16 мая, 2018 Опубликовано 16 мая, 2018 · Жалоба Вот мы и добрались до сути. На самом деле в SVN есть такая штука, как externals. Так далеко в SVN я еще не забирался ..... Фактически у меня сейчас так и сделано, но не на базе SVN, а просто - проекты лежат в одном месте, а общие библиотеки в другом месте, но рядом. Если пересобираю общие библиотеки, то зависимые проекты тоже нужно пересобирать. Т.е. все это делаю можно сказать "вручную". Если SVN это все упрощает и автоматизирует, то это - очень полезно! Короче, спасибо за подсказку ! .lib тут ни при чём, это второстепенная деталь.Одно другому не мешает - все это, имхо, дело вкуса и личных предпочтений ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zhevak 0 18 мая, 2018 Опубликовано 18 мая, 2018 · Жалоба В 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 18 мая, 2018 Опубликовано 18 мая, 2018 · Жалоба А как можно пользоваться библиотекой, если к ней нет документации (на край вменяемо написанных h-файлов)? Наугад тыкаться? :smile3046: Ви таки не поверите, почти все собранные библиотеки имеют политику частичного объявления. Это связанно с тем что они имеют внутренние, не публичные функции, предназначенные для собственной корректной работы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться