How to generate dSYM files on macOS

Hi, I’m trying to debug a plug-in (AudioUnit and VST3) crash on macOS. A user sent me crash logs but I can’t get anything useful from them as I don’t have any dSYM files. I’ve tried setting the “DWARF with dSYM” build option on both DEBUG and RELEASE builds but the dSYM folder in the resulting archive is empty. Could someone tell me where I’m going wrong?

GCC_GENERATE_DEBUGGING_SYMBOLS=YES

Hi Adam, where do I put this? I tried compiler settings and linker settings (in Projucer), but that caused the build to fail with ‘unknown file’ errors. I also tried preprocessor definitions, which builds but I still get no dSYN files.

Is there not a setting I can select in XCode itself to achieve the same thing?

I’ve been wondering about this recently too.

Found this SO post that looks promising: CMake with XCode target, generate debug symbols setting ignored for Release config - Stack Overflow

It’s in Custom Xcode flags:

1 Like

Sorry @adamwilson, I didn’t have time to check the Cmake equivalent. You can check what FRUT is doing with that Projucer setting and that will work. In addition to the answer on your SO post, I saw this in the docs:

https://cmake.org/cmake/help/latest/variable/CMAKE_XCODE_ATTRIBUTE_an-attribute.html

1 Like

@AdamVenn, thank you. I just tried adding this and also updated to the latest JUCE version which seems to address this issue, but it made no difference - if I look in the resultant archive, the dSYM folder is empty. Should I even expect there to be dSYM files? Or will plug-ins built with these flags produce crash logs with symbolic names? (You can probably tell I do 99% of my work on Windows!)

It’s supposed to generate the dsym files… I think they normally appear next to the plugin bundle in the build folder.

You could try this?
/Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild -project myplug.xcodeproj -configuration Release -quiet -jobs 8 GCC_GENERATE_DEBUGGING_SYMBOLS=YES STRIP_INSTALLED_PRODUCT=YES DEBUG_INFORMATION_FORMAT=dwarf-with-dsym build -target "myplug - AU" -target "myplug - VST"

1 Like

Or will plug-ins built with these flags produce crash logs with symbolic names?

You can check this with:

nm  path/to/my/plugin.vst3/Contents/MacOS/plugin -s __TEXT __text

If the symbols were correctly stripped then you’ll only have a few lines, if not it will spit out tons of lines where you can see your symbols.

I had issues in the past generating and stripping symbols with projects generated with the projucer (i now do this with cmake, here’s how i had it working Stripping symbols on plugins - #6 by static-cats).
What i ended up doing is having a different script for building the release build that would run pretty much the same as what AdamVenn mentioned:

xcodebuild -project plugin.xcodeproj -configuration "Release" GCC_GENERATE_DEBUGGING_SYMBOLS=YES STRIP_INSTALLED_PRODUCT=YES DEBUG_INFORMATION_FORMAT=dwarf-with-dsym STRIP_STYLE=non-global

The xcode project was generated with the projucer with the flag “Enable Plugin Copy Step” set to disable (can’t exactly remember why but it was important).

Hope this helps.

1 Like

Thank you for helping. I was able to get this all working, finding the dSYM files in the build folder (but the archive dSYM folder is still empty). The only problem I have now is that this build of my plug-in won’t load in Logic, although it loads without an issue in Reaper and Live and passes AU validation. The only thing I did different this time (apart from the dSYM stuff) was that I didn’t staple the resulting notorized build - does Logic not like that? I thought stapling was only necessary for offline use? Or might this be something to do with the dSYM changes?

I also found archived build missing dsym, how to fix?

I don’t really know what your problem might be but I can confirm that stapling is just for offline users and is not likely to be related to this problem.

I fixed the issue with my plug-in not loading in Logic. It was caused by me changing the bus setting in Projucer from {2,2} to {0,2}, then forgetting that I had done so (classic!). I changed it because my plug-in doen’t currently have an audio input, although earlier versions did. I haven’t overridden isBusesLayoutSupported() so I don’t know why Logic objected to the {0,2} format…

(Incidentally, it seems stupid that I can’t notorize plug-ins unless they’re zipped, but I can’t staple them unless they’re unzipped!)

I found this which might help: