Сбой бинарного файла при сборке с использованием PPC
Я разрабатываю программу для какой-то платы, которая использует PowerPC Architechture. Я только что сделал некоторые изменения в репозитории, немного изменил рефакторинг и переместил и стер классы.
На моей машине разработки (VM linux x64) двоичные файлы работают нормально и являются исполняемыми. Когда я строю с помощью CorssCompile Toolchain, он проходит без каких-либо ошибок и предупреждений. Но в целевой системе я не могу запустить программу, похоже, она даже не доходит до главной точки входа.
Так что я предполагаю, что я каким-то образом создал проблему связывания в проекте. Я просто не знаю, как распутать этого зверя.
Итак, мои вопросы, как я могу докопаться до ошибок, которые происходят до того, как была достигнута основная точка входа. Как я могу найти возможные циклические зависимости, существующие.
И просто для «веселья»: почему, по словам богов, он собирается и работает на x86, а не на ppc.
Да, я знаю, что это немного информации, чтобы действительно помочь, но я спрашиваю направления, вроде. Так как мне все равно придется иметь дело с этими проблемами несколько раз.
Решение
Почему, по словам богов, он будет собираться и работать на x86, а не на ppc.
Существует миллион возможных причин, от неработающей перекрестной цепочки инструментов до ошибок в libc и до неправильного вызова цепочки инструментов.
я прошу указания
Вы должны начать с компиляции этого источника:
int main() { return 0; }
и проверка его работоспособности (это проверяет базовую работоспособность цепочки инструментов). Если это так, вы расширяете его для печати чего-либо. Затем скомпилируйте его точно с флагами, которые вы используете в своем реальном проекте.
Если все это подтвердится, вы можете запустить свой настоящий проект под strace и / или GDB и посмотреть, если вы понимаете, где происходит сбой. Если вы этого не сделаете, отредактируйте ваш вопрос с помощью выходных данных инструментов, и кто-то может догадаться лучше.
Обновить:
Кажется, что инструментарий PPC или, скорее, его компилятор не знал, как обрабатывать статические переменные, объявленные после использования
Если бы это было правдой, вы бы получили ошибку компиляции. Вы не сделали, так что это неверно.
На Target: «gdb crash / app», а затем посмотрите на фреймы, где-то есть фрейм «__static_initialization_and_destruction_0», который должен даже указать вам на файл и указать строку, в которой используется еще необъявленная статическая переменная.
Ваш реальный проблема весьма вероятна в следующем: порядок построения глобальных (или статических) классов переменных в разных единицах перевода (т.е. разных исходных файлах) не определен (и обычно противоположен x86_64 а также ppc). Если у вас есть два таких глобала в разных файлах (скажем, A а также B), и если Bконструктор зависит от A После того, как ваша программа уже создана, она будет работать на платформах, где A построен раньше B, но вылетит на платформах где B пытается быть построен до A,
Другие решения
Других решений пока нет …