Моим первым выводом было бы перейти к нему, являющемуся результатом ошибки радара 5614542, отсюда и этот странный символ, но он не связан с ним.
Я сделаю некоторые предположения и угадаю из того факта, что кажется, что вы используете перемещения nlist, а не новые перемещения на основе байт-кода (вы можете проверить это, посмотрев команду dyld info load), это либо построен с использованием древней цепочки инструментов или является файлом MH_OBJECT для основного исполняемого файла, который не прошел последний этап компоновки. Я не уверен на 100%, если это так, но в любом случае,
Извините за мое предположение, приведенное выше, но первоначальный ответ по-прежнему применяется, если вы не хотите действительно отказываться от объединения символов, в этом случае создайте свое приложение с частной связью, но опять-таки этот шаблонный экземпляр делает символ слабым по очень веской причине. У него статический конструктор и неявно созданный шаблон, он предпочитает безопасность, поэтому хранит символ. Вы не можете экспортировать его вообще за пределы исполняемого файла, хотя у вас есть небольшой пример, программы на C ++ обычно используют такие вещи, как boost или библиотеки C ++, которые зависят от других библиотек C ++, которые создают цепочки, и в итоге вы получаете несколько определения в общем пространстве имен только из-за семантики C ++. В вашем небольшом тестовом примере вы можете справиться с этим, в более крупном приложении, если вы действительно не знаете, что делаете, и изучаете такие вещи, как деревья зависимостей для dylibs, просто позвольте dyld выполнять свою работу. Я думаю, что мой первоначальный ответ по-прежнему применим к основной части, поскольку объясняет, почему ваш символ помечен как слабый (ODR - это концепция, специфичная для C ++, но он обрабатывается разными статическими компоновщиками):
Для более подробного объяснения - это связано с семантикой C ++, а именно с правилом одного определения (ODR), которое является близким, но не тем же понятием, как неспособность иметь повторяющиеся сильные символы в одном и том же пространство имен (я имею в виду пространство имен ссылок, а не пространство имен C ++, это очень быстро сбивает с толку).
Если вы хотите знать, почему он помечен как слабый, то dyld сможет объединить его во время динамического связывания , поскольку повторное использование этого шаблона приведет к его повторному созданию (вызывая нарушение ODR и в зависимости от в контексте ошибки времени ссылки), поскольку это неявный экземпляр, который может требовать или не требовать объединения (что неизвестно до статического или даже динамического времени ссылки, если, конечно, вы не определите его как скрытое, в этом случае вы должны быть чрезвычайно осторожны поскольку семантика будет сильно различаться в зависимости от таких факторов, как модульная сборка или нет (я имею в виду «модули» LLVM, а не модули TS для C ++).
Если бы он не был слабым, вы бы вызывали нарушение ODR по правилам C ++, определяя его как скрытое для более чем 1 единицы перевода (если вы повторно используете этот шаблон, скажем, в заголовке внутри модуля, вы получите дублированный символ ошибки). Вы можете избежать нарушения ODR, так как оно на самом деле не применяется, но будьте готовы к некоторым неприятным сюрпризам (т. Е. С помощью немодулярных сборок, называемых «каждая единица перевода является модулем»).
Определяя его как слабое, dyld может выбрать правильные определения для каждого конечного связанного объекта, будь то общая библиотека или исполняемый файл (и не забывайте об общем кэше) в время выполнения и связывание / переместите их соответствующим образом в другое плоское пространство имен.
Вышесказанное - это многое, что можно вывести с помощью компилятора без какой-либо подсказки, скрытая связь - это действительно плохая идея, если вы не понимаете смысл, вам нужна internal видимость, если вы действительно хотите создать экземпляр и копировать шаблон каждый раз. В целом OSX имеет довольно сложную модель компоновки, на которой потенциально может быть множество мин.
И если я прав насчет вещи с объектными файлами, вам не следует запускать полоску на объектных файлах до того, как они будут поданы в статический компоновщик .