У меня есть общий сценарий:
Некоторые исходные файлы для исполняемого файла, которые зависят от некоторых стандартных библиотек и некоторых пользовательских библиотек. Все пользовательские библиотеки статически связаны с исполняемым файлом, тогда как стандартные библиотеки динамически связаны с ним.
Проблема:
Я полагаю, что у меня есть несколько определенных символов в моем полном пакете (исполняемый файл, который уже включает код пользовательской библиотеки + общие стандартные библиотеки). Компоновщик, очевидно, имеет представление об этом, но, как я понимаю, компоновщик не будет жаловаться, если не встретит несколько строго названных символов. Я боюсь, что когда я перемещаю свой код с платформы Solaris 8 / sparc на платформу solaris10 / sparc, в пользовательских библиотеках были реализованы некоторые стандартные функции Unix, которые приводят к сбою приложения во время выполнения. Обратите внимание, что приложение отлично работает на платформе Solaris 8 / Sparc
Я столкнулся со странными проблемами, которые заставили меня поверить, что это может быть источником
Что мне нужно:
Edit1:
С тех пор я знаю, что при создании файла карты с использованием ld в нем есть раздел с несколькими символами, через который я собираюсь найти имена, которые выглядят как вызов стандартной библиотеки. Для людей, которые не знают, компоновщик не сможет связать, только если он найдет несколько символов с одинаковым именем И имена являются строгими именами.
Вы можете включить генерацию MAP-файла в настройках компилятора (фактически компоновщика) и просмотреть в файле карты символы, соответствующие интересующим вас системным функциям UNIX. Возможно, вам придется написать скрипт для его автоматизации, но это будет хорошей отправной точкой. Ключ командной строки, вероятно, -map или что-то подобное, это будет зависеть от того, какой компилятор / компоновщик вы используете.
Фактическая проблема, которая происходила:
Библиотека (назовем ее lib1) имеет массив, как показано ниже
#define ARRAY_SIZE 1024
SomeStruct* global_array[ARRAY_SIZE];
Этот массив используется моей другой библиотекой (назовем ее lib2), которая, в свою очередь, используется моим приложением, используя для него объявление extern.
При компиляции lib2 (или это приложение не уверено) мы вообще не определили ARRAY_SIZE. Это каким-то образом привело к тому, что компилятор lib2 (или приложения), в свою очередь, неправильно рассчитал размер global_array, в результате чего он выделил память для какой-то другой переменной в месте, которое уже было выделено для global_array.
Определяя ARRAY_SIZE снова во время компиляции моих библиотек и приложений, все начинает вести себя нормально. Я не до конца понимаю, что вызвало проблему и почему ее удалось решить, поскольку внешнее объявление массивов не содержит размер. Кроме того, если библиотека действительно использовала MACRO ARRAY_SIZE, то почему компиляция не удалась? Кроме того, существует возможность, что имя, используемое для определения, является стандартным именем (фактическая строка была FD_SETSIZE).
Мои начальные ощущения насчет компоновщика были неправильными.