Как вы упакуете стандартные библиотеки gnu gcc stdc ++, gcc и gcc_eh?

Question

Без изменения и перекомпиляции сборок библиотек gnu gcc и stdc ++ мне нужно иметь возможность воспроизводить динамически загружаемые версии этих библиотек с другим встроенным сонамом.

Я подумал, что буду умнее, использую доступные статические версии и перепакую их примерно так: ld -E -shared -static "-lstdc++" -lgcc -lgcc_eh -o librepackaged_standard.so

librepacked_standard.so создан без предупреждений или ошибок, но ldd сообщает, что это не динамическая библиотека, а readelf сообщает только об этих основных символах:

Symbol table '.symtab' contains 4 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 0000000000201000     0 NOTYPE  GLOBAL DEFAULT  ABS __bss_start
     2: 0000000000201000     0 NOTYPE  GLOBAL DEFAULT  ABS _edata
     3: 0000000000201000     0 NOTYPE  GLOBAL DEFAULT  ABS _end

Я не уверен, почему ld не вводит все символы, определенные статически. Я также не знаю, есть ли какие-то другие специальные параметры, которые мне нужны, чтобы это работало.

Другой вариант - если есть известный кроссплатформенный способ простого изменения сонама, встроенного в исходные библиотеки elf. В настоящее время меня интересуют только двоичные файлы в формате эльфов. Я не заинтересован в написании собственного инструмента для изменения .soname в существующих двоичных файлах.

UPDATE: Причина, по которой символы не компилировались, заключается в том, что ld обрабатывает статические двоичные файлы иначе, чем файлы .o. По умолчанию он не импортирует символы из файла .a, если они не требуются другой библиотекой в ​​строке ссылки. Я исправил это с помощью опции --whole-archive.

Однако это дает мне еще одну ошибку: relocation R_X86_64_32S against _ZSt12_S_first_one 'нельзя использовать при создании общего объекта; при повторной компиляции с -fPIC and не удалось прочитать символы: Bad value` Они оба из libstdc ++. a в архиве bitset.o. Поэтому я не могу просто перекомпилировать .a в динамическую библиотеку, потому что компиляция GNU GCC по умолчанию не компилирует объектные файлы, используемые для статических библиотек с опцией PIC.

Это оставляет меня с поиском инструмента elf или перекомпиляцией GNU GCC с изменениями в его сборке.

Как указано в одном из ответов, вопросы лицензирования могут быть проблемой для любого из этих подходов. Мой лучший ответ заключается в том, что нам нужно изменить наши требования и найти другое решение, которое не предполагает какого-либо изменения или переупаковки стандартных библиотек GCC.

Answer 1

Причина, по которой символы не компилируются в разделяемую библиотеку, заключается в том, что ld обрабатывает статические двоичные файлы иначе, чем файлы .o. По умолчанию он не импортирует символы из файла .a, если они не требуются другой библиотекой в ​​строке ссылки. Ответом на этот конкретный вопрос является использование опции --whole-archive, и связывание файлов .a напрямую в основном работает.

Однако, чтобы это работало, файлы .o, включенные в статический архив, должны быть скомпилированы с использованием параметра -fPIC во время компиляции. Однако объектные файлы, используемые для статических библиотек, не компилируются с этой опцией в доступных статических библиотеках.

Таким образом, решение для изменения SONAME состоит в том, чтобы использовать двоичную утилиту ELF или перестроить GNU GCC, модифицированный для использования различных SONAME.

Поскольку в этой ситуации возникают проблемы с лицензированием, любое из решений не является практичным для проекта, поскольку оно не является открытым исходным кодом, и мы не хотим требовать распространения распространенной версии GNU GCC с измененным исходным кодом для всех наших платформ.

Answer 2

1. -static, вероятно, отменяет -shared.
2. Классически, вы извлекаете объектные файлы из статических библиотек, а затем упаковываете эти объектные файлы в общую библиотеку - полагаясь науниверсальное использование PIC (позиционно-независимый код), чтобы объекты в статических библиотеках можно было безопасно преобразовать в общую библиотеку.Возможно, вам удастся обойтись без этого шага извлечения, но я сомневаюсь в этом.
3. Возможно, вы захотите подумать, соблюдаете ли вы условия лицензирования.