Xcode“警告：找不到目标文件......没有可用的调试信息......”

Xcode "warning: Could not find object file ... no debug information available for ..."

提问by Elise van Looij

Messing about with various settings for unit-testing plug-ins left me with a discombobulated project file. I seem to have fixed it, but there is one side effect: everytime I run the plug-in, the console fills with warnings for each and every class file, like so:

搞乱单元测试插件的各种设置给我留下了一个混乱的项目文件。我似乎已经修复了它，但有一个副作用：每次运行插件时，控制台都会为每个类文件填充警告，如下所示：

warning: Could not find object file "/Users/elisevanlooij/Documents/Project Plug-ins/MyPlugin 8/build/MyPlugin.build/Debug/MyPlugin.build/Objects-normal/i386/MyPlugin.o" - no debug information available for "/Users/elisevanlooij/Documents/Project Plug-ins/MyPlugin 8/MyPlugin.m".

警告：找不到目标文件“/Users/elisevanlooij/Documents/Project Plug-ins/MyPlugin 8/build/MyPlugin.build/Debug/MyPlugin.build/Objects-normal/i386/MyPlugin.o” - 没有可用的调试信息对于“/Users/elisevanlooij/Documents/Project Plug-ins/MyPlugin 8/MyPlugin.m”。

Now I can quite understand why the error occurs since the path /Users/elisevanlooij/Documents/Project Plug-ins/MyPlugin 8 no longer exists: "MyPlugin 8" was temporary folder (a checkout for svn version 8 of MyPlugin) that has long since gone to the trashcan, which has been emptied too. The current version of MyPlugin should not even know about it, but somehow, for some reason Xcode and/or gdb won't let go. I've even thrown away the relevant caches in the Precompiled Headers Cach path, but no joy. Googling has revealed other people with the problem, but no solution. Who can help?

现在我可以完全理解为什么会发生错误，因为路径 /Users/elisevanlooij/Documents/Project Plug-ins/MyPlugin 8 不再存在：“MyPlugin 8”是临时文件夹（结帐 MyPlugin 的 svn 版本 8）自从去了垃圾桶，垃圾桶也被清空了。当前版本的 MyPlugin 甚至不应该知道它，但不知何故，由于某种原因 Xcode 和/或 gdb 不会放手。我什至扔掉了 Precompiled Headers Cach 路径中的相关缓存，但并不高兴。谷歌搜索已经发现其他人有这个问题，但没有解决方案。谁能帮忙？

These are the build settings (Debug) that have values. They are, by the way, as far as I can see, the same as a plug-in that does not have this problem.

这些是具有值的构建设置 (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 = 

采纳答案by Elise van Looij

I don't have a good answer to this question: I've considered removing the question, but it is a real problem and there are only one or two other mentions of it on the internet, with no solutions either. So, if you're struggling with this: I feel your pain but unfortunately the only way I've found to deal with it is to start a new project and import all classes and other resources. But please feel free to contribute and if you come up with something better than starting over, I'll be happy to award you the green V and upvote and all that.

我对这个问题没有很好的答案：我考虑过删除这个问题，但这是一个真正的问题，互联网上只有一两个其他提及，也没有解决方案。因此，如果您正在为此苦苦挣扎：我感到您很痛苦，但不幸的是，我找到的唯一解决方法是开始一个新项目并导入所有类和其他资源。但是请随时做出贡献，如果您想出比重新开始更好的方法，我将很乐意为您颁发绿色 V 和点赞等等。

回答by J.-P. Pellet

I had this problem as well while debugging a shared library. Turns out a wrong, outdated library was being loaded. Try typing 'info target' at the GDB prompt, and look at the paths to check that the object and library files are correct and are the ones that you have just built.

我在调试共享库时也遇到了这个问题。结果是加载了一个错误的、过时的库。尝试在 GDB 提示符下键入“info target”，并查看路径以检查对象和库文件是否正确以及是否是您刚刚构建的文件。

回答by Tyler Daniel

gdb is trying to load debugging information which is stored in the object files and not in the plugin. If you need to debug your plugin, the simplest solution is to keep the object files around. If you don't, then you can remove the [partial, incomplete] debug info from the plugin to get rid of the warnings with 'strip -S yourplugin'. I just ran into a related problem myself and answered more completely on this other question.

gdb 正在尝试加载存储在目标文件中而不是插件中的调试信息。如果您需要调试插件，最简单的解决方案是保留目标文件。如果不这样做，那么您可以从插件中删除 [部分，不完整] 调试信息，以使用“strip -S yourplugin”消除警告。我自己刚刚遇到了一个相关的问题，并在另一个问题上得到了更完整的回答。

回答by dalf

I had the same problem. When starting gdb I could see a lot of

我有同样的问题。启动 gdb 时，我可以看到很多

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

Then when doing "backtrace", I could only see the function names but not the line number.

然后在进行“回溯”时，我只能看到函数名称而不能看到行号。

The problem was that my binary was universal. In my make file, I was doing:

问题是我的二进制文件是通用的。在我的 make 文件中，我在做：

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

The solution to get rid of the warnings and to see the line number was to use only a single architecture.

摆脱警告并查看行号的解决方案是仅使用单一架构。

In your post I can see that you have a lot of architectures.

在您的帖子中，我可以看到您有很多架构。

VALID_ARCHS = i386 ppc ppc64 ppc7400 ppc970 x86_64

It's been long time now, but if you can, you can try with only one to see if you have the same problem.

现在已经很长时间了，但是如果可以的话，您可以只尝试一个，看看您是否有同样的问题。

Unfortunately this solution is not perfect, because in a perfect world I still want to continue to use a fat (universal) binary and be able to use gdb!

不幸的是，这个解决方案并不完美，因为在完美的世界中，我仍然希望继续使用胖（通用）二进制文件并能够使用 gdb！

GNU gdb 6.3.50-20050815 (Apple version gdb-1472)
gcc version 4.2.1 (Apple Inc. build 5664)

GNU gdb 6.3.50-20050815（Apple 版本 gdb-1472）
gcc 版本 4.2.1（Apple Inc. build 5664）

回答by Dylan_Larkin

How do I debug C++0x programs in MacPorts gcc 4.5?

如何在 MacPorts gcc 4.5 中调试 C++0x 程序？

adding -pedantic flag fixes this. Check the path that you are compiling from and if you don't see a .dSYM file, that is your culprit. That obv needs to be there per/executable, and for whatever reason -pedantic fixes this. I had the exact same problem until I stumbled on the above link.

添加 -pedantic 标志修复了这个问题。检查您正在编译的路径，如果您没有看到 .dSYM 文件，那就是您的罪魁祸首。该 obv 需要在每个/可执行文件中存在，无论出于何种原因 -pedantic 都可以解决此问题。在我偶然发现上面的链接之前，我遇到了完全相同的问题。

EDIT: Problem came back and my solution wasn't working, but then I remembered something I also did that I didn't mention: it seems switching the order of the files at the end of the command line seemed to regenerate the dSYM file. So in my case, I had a header file and to .c files. I just switched the order of 2 of them and problem solved. (don't know why this works, but I guess anything to trick the computer into viewing the compile as a new scenario)

编辑：问题又回来了，我的解决方案不起作用，但后来我想起了我也做过的一些我没有提到的事情：似乎在命令行末尾切换文件的顺序似乎重新生成了 dSYM 文件。所以就我而言，我有一个头文件和 .c 文件。我只是改变了其中 2 个的顺序，问题就解决了。（不知道为什么会这样，但我想有什么办法可以诱使计算机将编译视为新场景）

回答by Frederik Slijkerman

I just had the same problem after changing the build location of a Photoshop plug-in that I was working on. I moved the old build folder to the trash, but it turned out that Photoshop keeps an alias to the folder, which adjusts to the new location in the trash, so it would still load that old plugin from the trash, instead of the new one.

在更改我正在处理的 Photoshop 插件的构建位置后，我遇到了同样的问题。我将旧的构建文件夹移到了垃圾箱，但事实证明 Photoshop 为该文件夹保留了一个别名，该别名会调整到垃圾箱中的新位置，因此它仍然会从垃圾箱中加载旧插件，而不是新插件.

The 'info target' command pointed me to the problem.

'info target' 命令指出了这个问题。

回答by inket

I just had the same problem but with a framework.

我只是遇到了同样的问题，但有一个框架。

I fixed it by building the framework with Build Configurationset to Releasein the scheme.

我通过在方案中将Build Configuration设置为Release来构建框架来修复它。

回答by phunehehe

Not sure if this is your case, but when I had this problem it was because I forgot to add the implementation file to the test target.

不确定这是否是您的情况，但是当我遇到此问题时，是因为我忘记将实现文件添加到测试目标中。

回答by Employed Russian

You are still running the binary that was built from the old (removed) location, and you mustrebuild that binary.

您仍在运行从旧（已删除）位置构建的二进制文件，您必须重建该二进制文件。

The path to .ofiles is "baked" into MyPlugin.mat static link time.

.o文件路径MyPlugin.m在静态链接时被“烘焙” 。

There is no magic by which GDBwould remember that old location if you were debugging MyPlugin.mbuilt using object files in the new location.

GDB如果您正在调试MyPlugin.m使用新位置中的目标文件构建的，则没有什么魔法可以记住旧位置。