Big Sur compile/run error/uhoh

Hmmm not with emptyExample when I run it with build configuration as AppStore

@zach @Sam_McElhinney_io
Maybe the strip architecture step is not needed anymore. I’m not sure but now it is building correctly what platform you chose, after this recent change:

ok, sorry, but I might be wrong on the ‘does it work with other projects’ question after all.

I just tried archiving the ‘emptyExample’ with Appstore build settings and this is the error I got:

Entitlements:
emptyExampleAppStore.entitlements
Found:
/Users/smcelhinney/Library/Developer/Xcode/DerivedData/emptyExample-ddtgmdfupnxwvkgmnqhbpwtnankb/Build/Intermediates.noindex/ArchiveIntermediates/emptyExample Appstore/InstallationBuildProductsLocation/Applications/emptyExample.app/Contents/Frameworks/libfmod.dylib
Stripping invalid archs '/Us'
fatal error: lipo: can't open input file: /Us (No such file or directory)
Signing '/Us'
/Us: No such file or directory
Failed to sign '/Us'.
Command PhaseScriptExecution failed with a nonzero exit code

So, the same, after all?

Well, I’m pretty defeated. I’ve tried a full clear out and redownload of the OF folder into /documents, just in case. But that’s not helped at all.

So, when I try and archive emptyExample, using the AppStore build config, this is the consistent error I get:

When in frustration I delete the strip/sign script out, and try again, I get the following error also:

I don’t know what to do now - can anyone help?
S

Hmm it works for me but I think there is a bug with the ITEM iterations in the post build script. The space in the name of the scheme is causing issues with the iteration.

Can you try changing the scheme name to remove any spaces.

ie:

Then select manage schemes.

Then rename the scheme so there are no spaces:

Ok, I’ve tried that, removed the space, but still no good - same weird /Us error.

Here’s the run script view just in case + thanks for the suggestion anyhow

in the last screenshot you seem to have a group for your folder with an illegal name (I’m just guessing)
it is UCREATIVE\Domain Users, is that correct?
maybe /Us is part of the next parameter /Users/
You can check this in finder, command + I to have the folder information
Screen Shot 2021-12-04 at 10.49.14
Here you can see the user “z” and group “staff”
or check in terminal with

ls -alF /youropenframeworksfolder

If this is the case I would change this group name.

Ok, so, first of all, I am well out of my depth here. But I think I am nudging forward, and something feels broken

In the final run script (after the build stages) where the architectures are stripped out, I started experimenting, wondering if I could fix for what is going on (without actually knowing what is)

So, where it says:

echo "Identity:"
echo "${CODE_SIGN_IDENTITY_FOR_ITEMS}"

echo "Entitlements:"
echo "${CODE_SIGN_ENTITLEMENTS}"

echo "Found:"
echo "${ITEMS}"

# Change the Internal Field Separator (IFS) so that spaces in paths will not cause problems below.
SAVED_IFS=$IFS
IFS=$(echo -en "\n\b")

# Loop through all items.
for ITEM in $ITEMS;
do
echo "Stripping invalid archs '${ITEM}'"
lipo -extract x86_64 "${ITEM}" -o "${ITEM}"
echo "Signing '${ITEM}'"
codesign --force --verbose --sign "${CODE_SIGN_IDENTITY_FOR_ITEMS}" --entitlements "${CODE_SIGN_ENTITLEMENTS}" "${ITEM}"
RESULT=$?
if [[ $RESULT != 0 ]] ; then
echo "Failed to sign '${ITEM}'."
IFS=$SAVED_IFS
exit 1
fi
done

# Restore $IFS.
IFS=$SAVED_IFS

fi

I added the following:

while read -r ITEMS
do
 PATH_COUNT=$(echo "$ITEMS/" | grep -o '/' | wc -l)
 FILE_NAME=$(echo $ITEMS | cut -d '/' -f $PATH_COUNT | cut -d '.' -f 1)
 EXECUTE_FILE="$ITEMS/$FILE_NAME"
 
 echo $EXECUTE_FILE
done

So I have:

echo "Identity:"
echo "${CODE_SIGN_IDENTITY_FOR_ITEMS}"

echo "Entitlements:"
echo "${CODE_SIGN_ENTITLEMENTS}"

echo "Found:"
echo "${ITEMS}"

while read -r ITEMS
do
 PATH_COUNT=$(echo "$ITEMS/" | grep -o '/' | wc -l)
 FILE_NAME=$(echo $ITEMS | cut -d '/' -f $PATH_COUNT | cut -d '.' -f 1)
 EXECUTE_FILE="$ITEMS/$FILE_NAME"
 
 echo $EXECUTE_FILE
done

# Change the Internal Field Separator (IFS) so that spaces in paths will not cause problems below.
SAVED_IFS=$IFS
IFS=$(echo -en "\n\b")

# Loop through all items.
for ITEM in $ITEMS;
do
echo "Stripping invalid archs '${ITEM}'"
lipo -extract x86_64 "${ITEM}" -o "${ITEM}"
echo "Signing '${ITEM}'"
codesign --force --verbose --sign "${CODE_SIGN_IDENTITY_FOR_ITEMS}" --entitlements "${CODE_SIGN_ENTITLEMENTS}" "${ITEM}"
RESULT=$?
if [[ $RESULT != 0 ]] ; then
echo "Failed to sign '${ITEM}'."
IFS=$SAVED_IFS
exit 1
fi
done

# Restore $IFS.
IFS=$SAVED_IFS

fi

I was only doing this to try testing what is going on with ITEMS. But, when I hit ‘archive’ with this included, it went through; worked, with no errors called. Huh? This makes me think something is broken. Can anyone offer any insights?

N.B. This doesn’t solve my problem, as, when I try and upload to the notary service, I get the below error message. TBH I am not surprised, as I think something is still not right above.

If anyone can help me creep a bit further forward it would be hugely appreciated!

Oh, one other discovery:

if I hash out the line: IFS=$(echo -en "\n\b”)

to give:

# Change the Internal Field Separator (IFS) so that spaces in paths will not cause problems below.
SAVED_IFS=$IFS
# IFS=$(echo -en "\n\b")

# Loop through all items.
for ITEM in $ITEMS;
do
echo "Stripping invalid archs '${ITEM}'"
lipo -extract x86_64 "${ITEM}" -o "${ITEM}"
echo "Signing '${ITEM}'"
codesign --force --verbose --sign "${CODE_SIGN_IDENTITY_FOR_ITEMS}" --entitlements "${CODE_SIGN_ENTITLEMENTS}" "${ITEM}"
RESULT=$?
if [[ $RESULT != 0 ]] ; then
echo "Failed to sign '${ITEM}'."
IFS=$SAVED_IFS
exit 1
fi
done

then again the archive process runs through, with the following reports:

so maybe the /Us fail is caused by this line?

Buttttt… I still get the fail on upload to notarising, i.e. codesigning libfmod.dylib failed. duh.

Ok, it looks like I have finally got a result. I’m not going to say this is a solution, but I’ve got to the point of having a notarised app, again.

So, TLDR:

  • Line 82 of the final build phase script that reads: IFS=$(echo -en "\n\b”) was wrecking the path to the libfmod.dylib file, causing the lost /Us tag. I have no idea why, and I would really welcome anyone’s wisdom on explaining it. Hashing it out solves the issue and allows an archive with proper strip out and signing.

  • Beyond that, IT services’ ‘update and health check’ of my OS trashed all my apple dev certificates setup. I nuked them all (back up and delete all from keychain), restarted and then reset all the signing to automatic. And the second issue of failing to sign the libfmod.dylib was then magically solved too (i.e. the app now uploads to the notary service)

Phew. Thanks everyone who put comments above, they kept me thinking. Apologies for the long thread, but if it rescues someone else in future (including me, again) I guess it’s worth it.

Moral of the story? Don’t let strangers from IT update your OS. :crazy_face:

Sam

Hey I’m now experience the same thing you are describing, but it is all related to this script when I use AppStore scheme. in fact I can send to app store using Debug and Release without problems. I think they skip the lipo part (maybe there is no 32 bits anymore in libfmod?)

I’ve opened an issue here

1 Like

I’ve found a way to fix the script. I’ll be submiting a PR soon

1 Like