как из статической либы в объектник выдернуть функции?, GCC есть либа .а и файл .с, хочу позвать gcc -c, чтобы получился .о Опции

[yes]

то есть хочу вырезать дерево вызовов функций и обращений к глобальным данным из этой либы.
то есть в неком .с файле вызывается функция из этой либы и она что-то вызывает еще и т.д.

эта функция не main()

можно ли сделать так, чтобы не линковался экзешник, а некий промежуточный объектник, в который вошли бы только вызываемые функции, а остальная часть библиотеки не использовалась?

или хотя бы всю либу засунуть в этот объектник, секретность или уменьшение размера не сильно важно

----------------

после этот объектник слинкуют со своим кодом (там main()) некие юзера

какого-то особого смысла тут нет, человеческий фактор - не могут либу прикрутить к флоу, а объектник могут (какая-то гуи, куда вписать gcc-шные ключи не нашли)

[yes]

проблема оказалась слегка похуже, разные компилеры sparc-rtems- и sparc-elf- вроде бы из одних исходников собирались (Гейслером), но libc наверно разная (а может и интерналсы какие типа libgloss), вобщем "нахаляву" не получилось.
переписываю сейчас некоторые куски, которых там нет и собираю другим компилером.
вопрос остался интересен теоретически...

[alx2]

проблема оказалась слегка похуже, разные компилеры sparc-rtems- и sparc-elf- вроде бы из одних исходников собирались (Гейслером), но libc наверно разная (а может и интерналсы какие типа libgloss), вобщем "нахаляву" не получилось.

Извините, не понял. Что именно не получилось? И почему вы вообще говорите о компиляторах, если вопрос был о линковке?

[yes]

Извините, не понял. Что именно не получилось? И почему вы вообще говорите о компиляторах, если вопрос был о линковке?

вопрос возник потому, что моя библиотека не подлинковывалась к чужому проекту, хотелось минимально напрягаться для решения (мне казалось, что объектник вместо библиотеки - решение), также было подозрение, что, кроме моей либы, libc разная и какие-то функции в полном дереве нужно вытягивать и из нее

так как выяснилось, что это не типовая задача и ответа я не получил, то пришлось переделать исходники, надергать в них куски из libc (она тоже в исходниках) и т.д.

я не эксперт по компиляторам (скорее железячник, чем программист), но понимаю так : gcc требует libc, и еще несколько библиотек, которые не требуется даже указывать с -l линковщику
в конкретном sparc-*-gcc в эти библиотеки входит даже 2-3 RTOS | context switch-a, которые можно вызывать без подключения библиотек - это bare switch от Гейслера, freertos и pthread (? может им нужна библиотека типа -lpthread никогда не пользовал)

для конфигурируемых ecos или rtems собирается "ядро" в виде библиотеки и подключается. наверно, sparc-rtems-* содержит более простую версию поддержки железа (перекладывает это на "ядро"), то есть не хватало как раз лоу-левел функций типа управления прерываниями, манипуляций с кэшем и регистровыми окнами и т.п...

то есть все это специфично и разбираться в деталях мне не хочется,

---------------

но если есть универсальный метод в gcc/binutils-ах для манипулирования объектниками - мне хотелось бы знать, вдруг пригодится

Во первых Есть плагин к FAR который парсит elf файлы. таким образом статические библиотеки для фара -- папка со списком объектных файлов.

Во-вторых при линковке вы должны просто линковщику подать на вход список статических библиотек, он сам должен выдрать нужные функции.

по моему FAR это левак , ну то есть манипулировать elf-ами можно и самому, но хотелось бы стандартного метода

линковку производила "третья сторона" и линковщик ругался на отсутствие нужных функций, то есть мой вопрос можно сформулировать так : возможно ли часть линковки провести в одном окружении (с неким набором библиотек), а потом передать этот "частично слинкованый" объект для окончательной линковки в исполняемый файл ??