Xcode "предупреждение: не удалось найти объектный файл ... нет доступной отладочной информации для ..."

Question

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

предупреждение: не удалось найти объектный файл "/ Пользователи / elisevanlooij / Документы / Плагины проекта / MyPlugin 8 / build / MyPlugin.build / Debug / MyPlugin.build / Objects-normal / i386 / MyPlugin.o" - нет Отладочная информация доступна для "/ Пользователи / elisevanlooij / Документы / Плагины проекта / MyPlugin 8 / MyPlugin.m".

Теперь я вполне могу понять, почему возникает ошибка, поскольку путь / Users / elisevanlooij / Documents / Plug-ins проекта / MyPlugin 8 больше не существует: «MyPlugin 8» был временной папкой (извлечение для svn версии 8 MyPlugin) это давно ушло в мусорную корзину, которая тоже была опустошена. Текущая версия MyPlugin даже не должна знать об этом, но почему-то Xcode и / или gdb по какой-то причине не отпустят. Я даже выбросил соответствующие кэши в пути Precompiled Headers Cach, но не радости. Поиск в Google выявил других людей с проблемой, но не нашел решения. Кто может помочь?

Это настройки сборки (Debug), которые имеют значения. Они, кстати, насколько я вижу, такие же, как и плагин, у которого нет этой проблемы.

ARCHS = $(ARCHS_STANDARD_32_BIT)

SDKROOT = macosx10.5

ONLY_ACTIVE_ARCH = YES

VALID_ARCHS = i386 ppc ppc64 ppc7400 ppc970 x86_64

SYMROOT = build

OBJROOT = $(SYMROOT)

CONFIGURATION_BUILD_DIR = $(BUILD_DIR)/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)

CONFIGURATION_TEMP_DIR = $(PROJECT_TEMP_DIR)/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)

SHARED_PRECOMPS_DIR = $(CACHE_ROOT)/SharedPrecompiledHeaders

BUILD_VARIANTS = normal

DEBUG_INFORMATION_FORMAT = dwarf

ENABLE_OPENMP_SUPPORT = NO

GENERATE_PROFILING_CODE = NO

PRECOMPS_INCLUDE_HEADERS_FROM_BUILT_PRODUCTS_DIR = YES

SCAN_ALL_SOURCE_FILES_FOR_INCLUDES = NO

ALTERNATE_GROUP = $(INSTALL_GROUP)

ALTERNATE_OWNER = $(INSTALL_OWNER)

ALTERNATE_MODE = $(INSTALL_MODE_FLAG)

DEPLOYMENT_LOCATION = NO

DEPLOYMENT_POSTPROCESSING = NO

INSTALL_GROUP = $(GROUP)

INSTALL_OWNER = $(USER)

INSTALL_MODE_FLAG = u+w,go-w,a+rX

DSTROOT = /tmp/$(PROJECT_NAME).dst

INSTALL_PATH = $(HOME)/Library/Application Support/Twee Bomen plug-ins

SKIP_INSTALL = NO

COPY_PHASE_STRIP = NO

STRIP_STYLE = non-global

SEPARATE_STRIP = NO

STANDARD_C_PLUS_PLUS_LIBRARY_TYPE = dynamic

DEAD_CODE_STRIPPING = NO

LINKER_DISPLAYS_MANGLED_NAMES = NO

PRESERVE_DEAD_CODE_INITS_AND_TERMS = NO

LINK_WITH_STANDARD_LIBRARIES = YES

MACH_O_TYPE = mh_bundle

LD_OPENMP_FLAGS = -fopenmp

LD_MAP_FILE_PATH = $(TARGET_TEMP_DIR)/$(PRODUCT_NAME)-LinkMap-$(CURRENT_VARIANT)-$(CURRENT_ARCH).txt

GENERATE_MASTER_OBJECT_FILE = NO

PREBINDING = NO

KEEP_PRIVATE_EXTERNS = NO

SEPARATE_SYMBOL_EDIT = NO

LD_GENERATE_MAP_FILE = NO

APPLY_RULES_IN_COPY_FILES = NO

INFOPLIST_EXPAND_BUILD_SETTINGS = YES

GENERATE_PKGINFO_FILE = NO

FRAMEWORK_VERSION = A

INFOPLIST_FILE = Info.plist

INFOPLIST_OUTPUT_FORMAT = same-as-input

INFOPLIST_PREPROCESS = NO

COPYING_PRESERVES_HFS_DATA = NO

PRIVATE_HEADERS_FOLDER_PATH = $(CONTENTS_FOLDER_PATH)/PrivateHeaders

PRODUCT_NAME = MyPlugin

PLIST_FILE_OUTPUT_FORMAT = same-as-input

PUBLIC_HEADERS_FOLDER_PATH = $(CONTENTS_FOLDER_PATH)/Headers

STRINGS_FILE_OUTPUT_ENCODING = UTF-16

WRAPPER_EXTENSION = tbplugin

ALWAYS_SEARCH_USER_PATHS = NO

EXCLUDED_RECURSIVE_SEARCH_PATH_SUBDIRECTORIES = *.nib *.lproj *.framework *.gch (*) CVS .svn *.xcodeproj *.xcode *.pbproj *.pbxproj

VERSION_INFO_FILE = $(PRODUCT_NAME)_vers.c

VERSION_INFO_BUILDER = $(USER)

GCC_FAST_OBJC_DISPATCH = YES

GCC_AUTO_VECTORIZATION = NO

GCC_OBJC_CALL_CXX_CDTORS = NO

GCC_ENABLE_SSE3_EXTENSIONS = NO

GCC_ENABLE_SUPPLEMENTAL_SSE3_INSTRUCTIONS = NO

GCC_STRICT_ALIASING = NO

GCC_FEEDBACK_DIRECTED_OPTIMIZATION = Off

GCC_ENABLE_FIX_AND_CONTINUE = YES

GCC_GENERATE_DEBUGGING_SYMBOLS = YES

GCC_DYNAMIC_NO_PIC = NO

GCC_GENERATE_TEST_COVERAGE_FILES = NO

GCC_INLINES_ARE_PRIVATE_EXTERN = YES

GCC_MODEL_TUNING = G5

GCC_INSTRUMENT_PROGRAM_FLOW_ARCS = NO

GCC_ENABLE_KERNEL_DEVELOPMENT = NO

GCC_DEBUGGING_SYMBOLS = default

GCC_REUSE_STRINGS = YES

GCC_NO_COMMON_BLOCKS = NO

GCC_ENABLE_OBJC_GC = supported

GCC_OPTIMIZATION_LEVEL = 0

GCC_FAST_MATH = NO

GCC_ENABLE_SYMBOL_SEPARATION = YES

GCC_THREADSAFE_STATICS = YES

GCC_SYMBOLS_PRIVATE_EXTERN = NO

GCC_UNROLL_LOOPS = NO

GCC_MODEL_PPC64 = NO

GCC_CHAR_IS_UNSIGNED_CHAR = NO

GCC_ENABLE_ASM_KEYWORD = YES

GCC_PFE_FILE_C_DIALECTS = c objective-c c++ objective-c++

GCC_C_LANGUAGE_STANDARD = c99

GCC_CHECK_RETURN_VALUE_OF_OPERATOR_NEW = NO

GCC_CW_ASM_SYNTAX = YES

GCC_INPUT_FILETYPE = automatic

GCC_ALTIVEC_EXTENSIONS = NO

GCC_ENABLE_CPP_EXCEPTIONS = YES

GCC_ENABLE_CPP_RTTI = YES

GCC_LINK_WITH_DYNAMIC_LIBRARIES = YES

GCC_ENABLE_OBJC_EXCEPTIONS = YES

GCC_ENABLE_TRIGRAPHS = NO

GCC_ENABLE_FLOATING_POINT_LIBRARY_CALLS = NO

GCC_USE_INDIRECT_FUNCTION_CALLS = NO

GCC_USE_REGISTER_FUNCTION_CALLS = NO

GCC_INCREASE_PRECOMPILED_HEADER_SHARING = NO

OTHER_CPLUSPLUSFLAGS = $(OTHER_CFLAGS)

GCC_PRECOMPILE_PREFIX_HEADER = YES

GCC_PREFIX_HEADER = MyPlugin_Prefix.pch

GCC_ENABLE_BUILTIN_FUNCTIONS = YES

GCC_ENABLE_PASCAL_STRINGS = YES

GCC_FORCE_CPU_SUBTYPE_ALL = NO

GCC_SHORT_ENUMS = NO

GCC_USE_GCC3_PFE_SUPPORT = $(USE_GCC3_PFE_SUPPORT)

GCC_ONE_BYTE_BOOL = NO

GCC_USE_STANDARD_INCLUDE_SEARCHING = YES

GCC_PREPROCESSOR_DEFINITIONS = 

GCC_PREPROCESSOR_DEFINITIONS_NOT_USED_IN_PRECOMPS = 

Answer 1

У меня была такая же проблема. При запуске GDB я мог видеть много

"warning: Could not find object file...". 

Затем, когда я выполнял «возврат», я мог видеть только имена функций, но не номер строки.

Проблема была в том, что мой бинарный файл был универсальным. В моем файле make я делал:

gcc -ggdb -arch ppc64 -arch x86_64 ...

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

В вашем посте я вижу, что у вас много архитектур.

VALID_ARCHS = i386 ppc ppc64 ppc7400 ppc970 x86_64

Прошло много времени, но если вы можете, вы можете попробовать только один, чтобы увидеть, если у вас есть такая же проблема.

К сожалению, это решение не идеально, потому что в идеальном мире я все еще хочу продолжать использовать толстый (универсальный) двоичный файл и иметь возможность использовать gdb!

GNU gdb 6.3.50-20050815 (версия Apple gdb-1472)
gcc версия 4.2.1 (Apple Inc., сборка 5664)

Answer 2

У меня тоже была эта проблема при отладке разделяемой библиотеки. Оказывается, загружается устаревшая, устаревшая библиотека. Попробуйте набрать «info target» в приглашении GDB и посмотрите пути, чтобы убедиться, что файлы объектов и библиотек верны и являются только что созданными.

Answer 3

GDB пытается загрузить отладочную информацию, которая хранится в объектных файлах, а не в плагине. Если вам нужно отладить плагин, самое простое решение - сохранить объектные файлы. Если вы этого не сделаете, то можете удалить [частичную, неполную] отладочную информацию из плагина, чтобы избавиться от предупреждений с помощью 'strip -S yourplugin'. Я сам столкнулся с подобной проблемой и более полно ответил на этот другой вопрос .

Answer 4

Как отлаживать программы на C ++ 0x в MacPorts gcc 4.5?

добавление -pedantic flag исправляет это. Проверьте путь, по которому вы компилируете, и если вы не видите файл .dSYM, это ваш преступник. Этот obv должен быть там для каждого исполняемого файла, и по любой причине -pedantic исправляет это. У меня была точно такая же проблема, пока я не наткнулся на ссылку выше.

РЕДАКТИРОВАТЬ: проблема вернулась, и мое решение не работало, но потом я вспомнил кое-что, что я также сделал, что я не упомянул: кажется, переключение порядка файлов в конце командной строки, казалось, восстанавливает файл dSYM. Так что в моем случае у меня был заголовочный файл и файлы .c. Я просто переключил порядка 2 из них, и проблема решена. (не знаю, почему это работает, но я думаю, что что-нибудь, чтобы обмануть компьютер и посмотреть на компиляцию как новый сценарий)

Answer 5

У меня была такая же проблема, но с фреймворком.

Я исправил это, собрав фреймворк с Конфигурация сборки , установленной на Выпуск в схеме.

Answer 6

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

Команда 'info target' указала мне на проблему.

Answer 7

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

Answer 8

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

Путь к .o файлам "запекается" в MyPlugin.m во время статической связи.

Нет волшебства, с помощью которого GDB запомнит это старое местоположение, если вы отлаживали MyPlugin.m, созданный с использованием объектных файлов в новом местоположении.

Answer 9

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