Ошибка компоновщика "плохой кодовый код, указатель diff" с Xcode 4

Question

Перекомпиляция приложения C ++ для iPhone с Xcode 4 Я получаю эту неприятную ошибку компоновщика:

ld: bad codegen, pointer diff in __static_initialization_and_destruction_0(int, int)
to global weak symbol vmml::Vector2<float>::ZERO for architecture armv6

Кто-нибудь знает, что это значит? Конечно, было бы неплохо как-то уйти:)

Приложение скомпилировано и связано без ошибок в Xcode 3.

Редактировать : решение состоит в том, чтобы установить Символы, скрытые по умолчанию в Да во всех настройках сборки всех целей в проекте. Тем не менее, никто не знал, какова была настоящая проблема.

Answer 1

Решение состоит в том, чтобы установить Symbols Hidden By Default на Да во всех настройках сборки всех целей в проекте.Тем не менее, никто не знал, какова была настоящая проблема.

Answer 2

У меня была такая же проблема, и я также настроил параметры видимости.Тем не менее, я нервничал, просто возиться с видимостью символов и не понимая проблемы, поэтому я провел немного больше исследований.

Если, как и я, вы используете скрипт / пакет Пита Гудлиффа для создания boost в качестве фреймворкаскрипт устанавливает видимость по умолчанию скрытой (== да).Параметры видимости изменяют способ обозначения символов компилятором (по умолчанию, скрытый, внутренний).Эта информация используется компоновщиком при создании общих объектов elfs (разделяемых библиотек).Это не должно применяться здесь, поэтому я подозреваю, что это ошибка компоновщика.Внутри библиотеки буста у вас есть слабый символ, помеченный как скрытый, а затем в вашем проекте / другой библиотеке тот же символ, помеченный как стандартный.Компоновщик в замешательстве?

Что касается XCode 3 против 4, возможно, по умолчанию в 3 было скрывать символы?

В любом случае, изменение видимости по умолчанию на скрытый не должно иметь никакого эффекта сзадействованы только статические библиотеки, поэтому я чувствую себя намного безопаснее, выбирая этот маршрут.

Я опубликовал еще несколько деталей в записи в блоге для тех, кто заинтересован.

Answer 3

Я столкнулся с этой проблемой, пытаясь включить библиотеки boost в один из моих проектов.После нахождения этого поста установка Symbols Hidden By Default на Yes также решила эту проблему для меня.И я также должен был сделать ту же настройку в каждом из зависимых проектов, чтобы полностью избавиться от ошибки.

Просто к сведению - это произошло только с моими целями, которые использовали стек clang ++.Цели GCC и LLVM + GCC, похоже, не затрагиваются.

Answer 4

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

Answer 5

Возможно, вы используете библиотеку со скрытой информацией о символах. Если символ не был экспортирован из вашей библиотеки, и вы пытаетесь использовать его извне, это приводит к аналогичной ошибке компоновщика. Казалось бы, правильное решение состоит в том, чтобы найти способ сделать этот символ «видимым» для внешнего мира через определения макросов GCC и / или изменить саму библиотеку, чтобы убедиться, что этот конкретный символ действительно «скрыт» от внешнего мира - -ie это не то, что когда-либо использовалось или отображалось в заголовочном файле.

Однако, будьте осторожны: в соответствии с документацией Apple, вам не следует прятать некоторую символьную информацию по ряду причин; этот, перечисленный ниже, кажется самым тревожным из всех:

Если ваш символ использует информацию идентификации типа времени выполнения (RTTI), исключения или динамическое приведение для объекта, определенного в другой библиотеке, ваш символ должен быть видимым, если он ожидает обработки запросов, инициированных другой библиотекой. Например, если вы определяете обработчик перехвата для типа в стандартной библиотеке C ++ и хотите перехватывать исключения этого типа, генерируемые стандартной библиотекой C ++, вы должны убедиться, что ваш объект typeinfo видим.

Источник: http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/CppRuntimeEnv/Articles/SymbolVisibility.html

Таким образом, если вы хотите поймать исключение из библиотеки, с которой вы ссылаетесь, скрытие информации о символах представляется плохим выбором. Правильным решением было бы показать символы любой библиотеки, на которую вы ссылаетесь. Это можно сделать с помощью , пропустив следующие флаги компилятора GCC:

-fvisibility=hidden --fvisibility-inlines-hidden

(видимости по умолчанию должно быть достаточно), или есть также прагмы компилятора, которые позволяют вам сделать это. Смотри: http://gcc.gnu.org/wiki/Visibility