I have a program which I build using automatic-ref-counting and the Lion SDK. This program doesn't behave as expected in Snow Leopard, (One view won't be loaded and opening a document hangs the program.) so I want to debug it there. But because I can't compile it under Snow Leopard I have no idea how to do so.
So how do I get the debugging symbols into gdb or can I debug this thing in Xcode - is there probably a remote way or something like that?
You can either debug remotely via gdbserver:
snow-leopard$ gdbserver :10000 /path/to/exe
lion$ gdb /path/to/exe
(gdb) target remote snow-leopard:10000
A simpler way is to copy your entire source and build directory to snow-leopard and debug with GDB locally. Even though you didn't build there, GDB should still be able to find everything it needs.
Sorry to say, my research shows that the "g++" compiler on Snow Leopard no longer places symbols in the linked module that have any meaning to "gdb". The only symbols found are the made-up symbols created to make ALL symbols unique. Here is a brief sample:
`_Z5DoSVCi', function, 0x151dd
`_Z7SEBTrapv', function, 0x1383c
Those same symbols in Tiger were like this:
`_Z5DoSVCi' `DoSVC(int)', FUNCTION, 0x1394c
`_Z7SEBTrapv' `SEBTrap()', FUNCTION, 0xf994
The "signature" is what "gdb" needs to resolve things like: break emsvc.c:DoSVC
Furthermore, you must still have all the "object decks", like emsvc.o, because Snow Leopard's "g++" apparently does not carry the symbols in the linked module anymore.
I brought a "g++" compiled module linked on Tiger (Intel-based) over to Snow Leopard without object decks, and "gdb" was able to handle it perfectly, including setting breakpoints. Apparently, "g++" or the linker isn't producing proper modules for "gdb" on Snow Leopard.
Related
I have an application in the Mac App Store. I'm trying to support users going back to Snow Leopard but this is becoming increasingly difficult.
Recently I've hit a roadblock due to the iTunesLibrary.framework, this framework must be linked to the main executable and yet doing so will always trigger a crash on load when running in Snow Leopard.
To workaround this problem, I want to compile a version of my app that doesn't use features and frameworks from newer versions of OSX. The problem is, how can I launch the compatibility build automatically?
I'm considering trying to make the main executable point to a shell script, but I don't really like that idea. I've also thought of the main executable being a helper that simply launches the full app and then exits. I expect this would work, but I worry about it getting approved by Apple. Finally, I'm wondering if the app bundle format itself can support this kind of setup, maybe via an advanced used of CFBundleExecutable that I'm unaware of.
Has anyone been down this road, what would you suggest?
Try weak linking the frameworks, more information about Weak Linking and Apple Frameworks here. Then also check in your code for the OS version or - (BOOL)respondsToSelector:(SEL)aSelector of any NSObject to determine what you can call and what not.
To have Snow Leopard as Base SDK you'll need an old Xcode and will have troubles submitting to Mac App Store.
I'm making an application that depends on webkit, with some modifications to the webkit code. Thus, I need to use a private framework. I've made the install path of the framework relative to the executable using the #executable_path directive.
On Snow Leopard, everything works perfectly. However, on OS X Lion, dyld loads the system webkit (the one used by Safari) in addition to my private framework. This extra load only happens after I right click on the WebView and select "Inspect Element." I would have to do some deeper debugging to figure out which import exactly is causing dyld to go hunting. In the build output, I see no indication of linking to the external webkit, so I'm at a loss as to why this is happening, especially since it worked on Snow Leopard.
I don't want to change the DYLD_LIBRARY_PATH environment variable as this application needs to be distributed to other machines - users should be able to just run the app.
I suppose I could change the name of the framework and see if that fixes the issue. I'll update this question with the result of investigating the symbol that causes dyld to go looking for the system webkit, as well as making the framework name unique, but any thoughts here would be helpful.
I'm building an application that takes advantage of Mac OS X 10.6-only technologies, but without giving up backwards compatibility to 10.5 Leopard.
The way I do this is by setting the 10.6 SDK as the base SDK, weak-linking all frameworks and setting the deployment target to 10.5 as described in:
http://developer.apple.com/mac/library/DOCUMENTATION/MacOSX/Conceptual/BPFrameworks/Concepts/WeakLinking.html
This works fine; before making a call that is Snow Leopard-only I need to check that the selector or indeed the class actually exist. Or I can just check the OS version before making the call.
The problem is that this is incredibly fragile. If I make a single call that is 10.6 only I blow Leopard-compatibility. So using even the normal code code completion feature can be dangerous.
My question: is there any way of checking which calls are not defined on 10.5 before doing a release build? Some kind of static analysis, or even just a trick (a target set the other SDK?) would do.
I obviously should test on a Leopard machine before releasing anything, but even so I can't possibly go through all paths of the program before every release.
Any advice would be appreciated.
Best regards,
Frank
You could change the target SDK to 10.5. The compiler will then output warning: definition for '-snowLeopardOnlyMethod:' not found messages.
I am trying to compile lanshark for mac, but do not know how to compile on mac. I am guessing that it is possible to compile linux source code on mac. if not how can i get this program to run?
A mac is, under the hood, a BSD 'darwin' box.
Go and take a look at the MacPorts webpage. You'll find lots of interesting information (like where to get a compiler etc ) there.
Another place to go for an apple development environment is apple (xcode) ...
It should be possible to get that to run, but it will be a bit of work. The source may need a small amount of modification, depending on exactly how the protocol works (if they're using raw ethernet, that is done quite differently). Also, the OS X linker (ld) works completely differently to the Linux linker, and so the build system will need a bit of tinkering.
However, the compilers and build utilities are in the XCode bundle on your install disk, or at the download link in the other answer, so install that and give it a go. If you're lucky, just following the Linux instructions will build it.
I downloaded LibC source from opensource.apple.com, but since it's part of one monolithic library /usr/lib/libSystem.B.dylib would I have to somehow rebuild the entire thing?
I have a BSD command line program, ported from Linux. I want to be able to set breakpoints in LibC functions and step through. I'm trying to close in on what seems to be heap corruption in my program (which doesn't occur on Linux - I've already ported back to Linux and run memcheck there.)
Have you take a look at the Kernel Debug Kit from Apple (http://developer.apple.com/sdk/) ? I know that it contains kernel symbols, but I am not sure if libc is part of the SDK.
You can build Valgrind yourself - either use the last version released on 10.5, or look on the bug tracker for the Snow Leopard support bug, which has a patch.
Alternately, try the memory debugging tools in the malloc(3) manual.