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

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".

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?

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.

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_开发者_StackOverflow社区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 = 

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 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.

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

"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:

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!

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

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.

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

The path to .o files is "baked" into MyPlugin.m at static link time.

There is no magic by which GDB would remember that old location if you were debugging MyPlugin.m built using object files in the new location.

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.

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

I just had the same problem but with a framework.

I fixed it by building the framework with Build Configuration set to Release in the scheme.

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

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.

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)

You need to change GENERATE_DEBUGGING to NO. Then clean the project and build again it will be fixed

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 accept your answer.