C++ – Xcode breakpoints only hit when set during debugging

I’m porting a C++ sdk from Windows to Mac OSX 10.5. I have a problem in Xcode where my breakpoints in certain files will only be hit if I set them while debugging. If I stop debugging and then restart, the breakpoints no longer get hit. If I add them while not debugging, they don't get hit. This is only in certain files and my breakpoints are always dark blue. i.e. I can’t tell the difference between a breakpoint that will get hit and one that won’t.

Specifically, my sdk is made up of various dynamic libraries. These are built using Perforce jam, which calls the various compile and link executables depending on my OS and compiler version (such as Visual Studio’s cl.exe and link.exe). I have a simple (unit testing) command line application that links to these dynamic libraries and calls code in them. This application on Windows is a Visual Studio project, in which I set breakpoints on library code and expect them to be hit.

I’ve created the same C++ command line utility application in Xcode 3.1.2 that links to the sdk dylibs and calls code in them. Some of the breakpoints work fine. I can set breakpoints in code that’s called from the troublesome code, and step out to the troublesome code, which I can then step through fine. The troublesome code is compiled into the same dylib as code that works fine. It’s also long and complicated enough not to be a candidate for inlining.

I’ve tried the following:

• Turn Load symbols lazily off.
• Compile with both gcc 4.0 and gcc 4.2.
• Do a full clean and shutdown.
• Delete the user-specific files of the xcodeproj package.
• Rename the files so they can’t clash with system files.
• Clear everything out of the Breakpoints window.
• Create a new Xcode project.

My application is compiled in debug with DWARF format and my libraries are built with the –g flag (along with –v, –arch i386 and –fvisibility-inlines-hidden).

Help would be much appreciated. Thanks.

Update: sorry for not updating this, my Mac port project was postponed. I never resolved this, but discovered that it actually only occurs in constructor bodies. I'll revisit this as and when I hit the problem again.