AU fails and strip symbols

I’ve recently updated to the develop tip and my build script is generating AU that fails to load with auvaltool. The culprit is this command:
strip -x -S

I’ve always used that command to strip symbols, never let Projucer do it, but now, for some reason, it causes the AU to fail when testing with auvaltool. The only error I get is a simple
zsh: killed

Now, did something change regarding symbol strips? If I enable it in Projucer, will it be the same as the “old” strip -x -S ?

I’m on a M1 MacBook with Xcode 12.5

All binaries must be signed in order to load successfully on M1 machines.

It’s worth checking whether running strip causes the code signature of the plugin to become invalid, by checking the signature before and after running the strip command. If the signature is invalid after running strip, you will need to re-sign the binary before attempting to run it.

Yes, I always sign after the strip command. But, there’s something I’ve noticed, it looks like since I’ve updated to the develop tip, even though the Code-Signing Identity field is empty in my Projucer project, it still signs the plugin. I’ll do more tests, but something definitely changed recently that’s messing with my builds.

I’m only aware of one recent signing change, specifically:

If no signing identity is specified, Xcode will now sign the binary to run locally. I’d be a bit surprised if this was causing the problems you’re seeing, but it might be worth checking before and after that commit to see whether it has any effect.

I think I ran into a very similar issue today:
I also do the stripping and signing myself in a script that I run after the build, and am now seeing warnings since master 6.1.3:

Is there any way to make the Projucer not set the signing to “Sign to run locally”?

And does anyone indeed know if enabling code stripping in the Projucer has the same effect as doing strip -x -S?

I now run codesign --remove-signature before the strip command, and then resign correctly with my certificate.

Thanks, good to hear that codesign --remove-signature works fine then (I had read a few horrible posts about it not working correctly on Stack Overflow, but these were older posts, so I guess it should be fine now if you’re using it on all your plugins in the wild). That should help for the AU and VST version then.

BTW: did you ever find out if the “Strip symbols” option in the Projucer does the same as strip -x -S?

Last question: how do you handle the AAX version now that Xcode signs that .aaxplugin bundle too?
Until now, I always did this in a post-build script defined in the Projucer (and thus ran by Xcode):

if [ "$TARGETNAME" = "SaltyGrain - AAX" ] ; then
  echo Copying presets into AAX bundle
  mkdir -p $CONFIGURATION_BUILD_DIR/$FULL_PRODUCT_NAME/Contents/Factory\ Presets/SaltyGrain/
  cp -R $PROJECT_DIR/../../Source/Presets/AAX/ $CONFIGURATION_BUILD_DIR/$FULL_PRODUCT_NAME/Contents/Factory\ Presets/SaltyGrain/
  echo Stripping binary in AAX bundle
  xcrun strip -S -x $CONFIGURATION_BUILD_DIR/$FULL_PRODUCT_NAME/Contents/MacOS/SaltyGrain
  echo Signing AAX build
  /Applications/PACEAntiPiracy/Eden/Fusion/Current/bin/wraptool sign --verbose --account samplesumo --signid "Developer ID Application: SampleSumo (PV***********)" --wcguid *******-****-****-****-************ --dsigharden --in $CONFIGURATION_BUILD_DIR/$FULL_PRODUCT_NAME --out $CONFIGURATION_BUILD_DIR/$FULL_PRODUCT_NAME

so I only sign with (AVID) wraptool, and don’t (Apple) codesign the aaxplugin bundle.
But with the change in JUCE 6.1.3, the wraptool-signed aaxplugin bundle now also gets signed with Apple codesign by XCode: is that OK (doesn’t it break AVID’s wraptool signature)?

I’m not sure, I suspect it’s not the same kind of strip, that’s why I kept it in my build script.
I don’t run any post-build script with Projucer, I have a bash script with all the build steps I need (using xcodebuild etc…) so I just remove any signature from the AAX too and then resign it again correctly with wraptool

Yeah, that’s also why I have the strip in my script: you’re sure what actually gets executed then. Maybe I’ll experiment a bit later on to see if it’s doing the exact same thing or not.

What you do for the AAX version (remove Xcode’s signature + call wraptool from your own script later on) could indeed be a workaround, but I was doing it from Xcode’s post-build actions because I could then just easily build it from Xcode and my plugin would already contain the presets in it’s bundle (I copy them in there in that post-build phase) and be signed with wraptool, ready to go if I want to try it, without having to run an extra script after the Xcode build (which I only do when I make a full test release installer normally).
I’ve continued my findings for AAX in the topic I had started and mentioned above.