6

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_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 =
Translunar
  • 3,739
  • 33
  • 55
Elise van Looij
  • 4,162
  • 3
  • 29
  • 52
  • 1
    Note for others in the same predicament: I never did solve the problem. I finally created a new project and imported the class and other files out of the messed-up project. Which, with Subversion getting in the way, fills a good part of the afternoon. – Elise van Looij Nov 21 '09 at 12:30

10 Answers10

1

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.

J.-P. Pellet
  • 11
  • 1
  • A new answer after two months, that's great. Now I'll have to figure out a way to test verify Mr. Pellet's suggestion since I did start all over again plus I upgraded to Snow Leopard. Eh, this is going to take me a while, unless someone happens to have this problem and can replicate this solution? – Elise van Looij Jan 15 '10 at 18:54
  • `info target` does work for me, but none of the listed items match the path of the missing object file. – Translunar May 07 '13 at 19:08
1

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)

dalf
  • 582
  • 4
  • 11
1

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.

Community
  • 1
  • 1
Tyler Daniel
  • 656
  • 6
  • 15
  • Thanks for the answer and the cross-reference. The situations are not the same (you seem to assume that the files and the plug-in are two separate entities when in fact, I was trying to compile and run the plug-in), but nevertheless anyone running into this problem might want to experiment with the "Strip Linked Product" and other strip-related Build Settings. – Elise van Looij Apr 12 '11 at 13:22
0

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.

phunehehe
  • 8,618
  • 7
  • 49
  • 79
  • Didn't have a test target anymore, but I tried it and unfortunately it didn't work. Thanks for taking the trouble to answer. – Elise van Looij Nov 12 '09 at 18:53
  • By the way, I ran into this the other day as well. Apparently SenTest complains if it can't find at least one method starting with test as in (void)testDiscombobulationOfSwallows – Elise van Looij Nov 21 '09 at 12:26
0

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.

Employed Russian
  • 199,314
  • 34
  • 295
  • 362
  • Right, but how? I'm just a simple Xcode user, Clean and Build & Run are the full extent of my binary-building skills, I'm afraid. – Elise van Looij Nov 13 '09 at 08:58
  • Thanks for taking the trouble to answer, but I don't think your answer is correct: if any path information were really baked into .m files I would have gotten errors when I created a new project and imported the .h and .m files. Instead, they ran and run just fine. – Elise van Looij Nov 21 '09 at 12:33
0

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.

halfer
  • 19,824
  • 17
  • 99
  • 186
Elise van Looij
  • 4,162
  • 3
  • 29
  • 52
  • I really wish you hadn't checked this non-answer. I get a similar problem not with my project but with headers included from my project. – Translunar May 07 '13 at 19:07
  • 1
    I understand your disappointment, but in the years since I've posted this question, I've learned that there is not one definitive answer. I could remove the question, but this page is visited quite a bit and it does serve a purpose as a gathering-place for possible solutions and approaches. Perhaps something here will inspire you and perhaps you'll be kind enough to share your solution. – Elise van Looij May 18 '13 at 11:57
0

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.

Frederik Slijkerman
  • 6,471
  • 28
  • 39
  • Something holding a reference to a discarded file, in your case Photoshop, in my case Xcode or gdb -- or so I thought at the time. Could there be a common culprit? Could the Finder be involved or is there some other process that keeps track of plug-ins and or bundles? I'm just thinking out loud here. Anyway, thanks for contributing to this thread in which no one seems to ever gain any points except spiritually or something like that. – Elise van Looij Mar 10 '10 at 15:41
  • It's just how applications (used to) store references to files on the Mac -- if you move the file or folder that is referenced, the reference is updated behind the scenes; even if it is moved to the Thrash. Regarding gaining points, it looks like the problem is solved. :-) – Frederik Slijkerman Mar 11 '10 at 19:34
0

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)

Community
  • 1
  • 1
Dylan_Larkin
  • 503
  • 4
  • 15
0

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.

inket
  • 1,641
  • 16
  • 21
  • Cool, another answer in this much-visited (1 kViews!) but doomed-to-remain-unsanswered thread. Did you use Xcode 3 or Xcode 4? I've had no end of linker problems in Xcode 4, but this particular error has as yet not popped up. Perhaps you would expand your answer by including your deployment build settings, both for debug and release? – Elise van Looij Mar 31 '11 at 16:31
  • I used Xcode 4. Weird thing is, while writing this comment I tried replicating the problem to no avail. :/ Maybe it's just a random problem that requires a re-run/build of the plugin/framework ? – inket Mar 31 '11 at 19:25
  • It *does* pop-up at seemingly random intervals -- which is what makes it so aggravating. That's what this thread is for, to offer solace to those afflicted by this maddening problem. And perhaps gain some wisdom along the way. Thanks for sharing! – Elise van Looij Apr 04 '11 at 11:10
0

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

Mustafa Ozhan
  • 321
  • 6
  • 9