Open dotMorten opened 1 year ago
rolfbjarne
commented
1 year ago I can reproduce the problem, and it seems to be a buffer overrun in the strip command. I'm still investigating to figure out if this is something we can work around somehow.
madmapper
commented
1 year ago Thanks for spotting this @dotMorten - we are in the middle of updating an app with Runtime 200 and this was driving me nuts
adamdeets-hdr
commented
1 year ago Seeing the same issue.
madmapper
commented
1 year ago FYI unchecking "Strip native debugging symbols" in the Project Properties accomplishes the same thing and everything seems to work as expected.
dotMorten
commented
1 year ago FYI unchecking "Strip native debugging symbols" in the Project Properties accomplishes the same thing
Yup that's the same as setting MtouchNoSymbolStrip (but the designer always does it bad with weird conditions so I like doing it in the project directly).
Just note that this is not a workaround you really want - this should be considered a temporary fix to unblock our work, until this issue has been addressed.
A better workaround is probably to move back to xcode 14 for now.
dotMorten
commented
1 year ago Just posting the comments from Discord triage here (thanks @rolfbjarne):
It's a buffer overrun:
t's a buffer overrun
diff --git a/misc/strip.c b/misc/strip.c
index 2a04cec..0c004bb 100644
--- a/misc/strip.c
+++ b/misc/strip.c
@@ -4058,6 +4058,7 @@ enum bool *nlist_outofsync_with_dyldinfo)
new_strsize = rnd32(new_strsize, sizeof(int32_t));
else
new_strsize = rnd32(new_strsize, sizeof(int64_t));
+ new_strsize *= 2;
new_strings = (char *)allocate(new_strsize);
/*looks like the code that computes the size of all the strings doesn't quite match the code that copies strings around
dotMorten
commented
1 year ago With the latest RC2.1 workload update that shipped yesterday, it appears that Xcode 15 is now required, so we no longer can work around this issue. This makes it a complete showstopper today, rather than in May when XCode 15 will be required by the app store.
dalexsoto
commented
1 year ago @dotMorten I know it's not ideal but can you try Xcode 15.1 Beta 2 to see if it is solved there? We do need some validation.
rolfbjarne
commented
1 year ago This is not fixed in Xcode 15.1 beta 2 :/
rolfbjarne
commented
1 year ago I submitted a ticket using Apple's feedback assistant (FB13327641), let's see what they say.
If I have time, I'll try to see if there's a way to work around it (won't be this week unfortunately).
dalexsoto
commented
1 year ago Thanks a lot @rolfbjarne!
rolfbjarne
commented
1 year ago I think I figured out the problem with strip, and created a pull request: https://github.com/apple-oss-distributions/cctools/pull/2
rolfbjarne
commented
1 year ago @dotMorten can you try adding this to your csproj to see if it fixes the problem?
<PropertyGroup>
<_ExportSymbolsExplicitly>false</_ExportSymbolsExplicitly>
</PropertyGroup>@rolfbjarne That does appear to workaround it as well. What does this do?
rolfbjarne
commented
1 year ago For every P/Invoke, we tell the native linker that it can't remove the symbol in question.
We used to do this by passing -usymbol for each symbol to the native linker, but in .NET 8 we switched to creating a file with all the symbols, and passing the file to the native linker with -exported_symbols_list [file].
Setting _ExportSymbolsExplicitly=false switches back to the old behavior, passing symbols with -usymbol.
arnsteinjo
commented
1 year ago Adding
`
`
fixes the issue on iOS, but now I am unable to load resources (Images, Fonts, ...) for Android so best to use a conditional:
<PropertyGroup Condition="'$(TargetFramework)' == 'net8.0-ios'">
dotMorten
commented
1 year ago Not sure why, but today with .NET 8 RTM + XCode 15.0.1 I'm not seeing this issue. Can anyone else confirm this?
rolfbjarne
commented
1 year ago I can't reproduce either.
Note that this doesn't mean all is good: the bug is a memory corruption inside strip, which means we get random behavior, and today that random behavior might be "works as expected."
rolfbjarne
commented
2 months ago This seems to have cropped up again in Xcode 16.0 :/
If anyone runs into this, please file a feedback ticket with Apple.
Feel free to reference the pull request with the fix: https://github.com/apple-oss-distributions/cctools/pull/2, and also the existing feedback ticket I raised (FB13327641).
dotMorten
commented
1 month ago Yup I'm seeing it too! Submitted FB15289922
activa
commented
1 month ago As a workaround, reverting to the 8.0.402 workload fixed the iOS build issue, even with Xcode 16 installed.
Which makes me wonder if this is even an issue with Xcode 16.
AdamDiament
commented
1 month ago As a workaround, reverting to the 8.0.402 workload fixed the iOS build issue, even with Xcode 16 installed.
Which makes me wonder if this is even an issue with Xcode 16.
Confirmed working on xcode 16 with dotnet workload install maui-ios --version 8.0.402
corne-ac
commented
1 month ago adding <MtouchNoSymbolStrip>true</MtouchNoSymbolStrip>to my PropertyGroup worked, but causes no breakpoints to work or debug console writing to work. At least. I can run the application for a start.
dotMorten
commented
1 month ago @corne-ac definitely just a workaround. You don't want to ship apps built with that switch
rolfbjarne
commented
1 month ago I've submitted a DTS with Apple for this issue, let's see what they say.
UsherNet
commented
1 month ago As a workaround, reverting to the 8.0.402 workload fixed the iOS build issue, even with Xcode 16 installed. Which makes me wonder if this is even an issue with Xcode 16.
Confirmed working on xcode 16 with
dotnet workload install maui-ios --version 8.0.402
Thanks for the assistance.
Changing workload allows release build to be created and tested on device... thank you. Issue now that I can't run on iOS Simulator with Xcode 16, so I switched back to Xcode 15 which compiles and runs, only to crash on launch with an issue in CommunityToolkit.Maui (9.1). Rolling that back to 9.0.3 allows me to continue development.
So currently using workload 8.0.402, CommunityToolkit.Maui 9.0.3 and Xcode 15 to allow local development and deployment to device.
bryandam
commented
1 month ago As a workaround, reverting to the 8.0.402 workload fixed the iOS build issue, even with Xcode 16 installed.
Which makes me wonder if this is even an issue with Xcode 16.
Also confirmed this has fixed our pipeline, thanks for the heads up. (Subscribing for final solution)
Kudos to @rolfbjarne for submitting an actual fix to Apple.
rolfbjarne
commented
1 month ago I've submitted a DTS with Apple for this issue, let's see what they say.
"There is no workaround DTS can provide for Feedback ID FB13327641; it is still under investigation. Please continue to track the problem via the bug report."
The issue itself says:
Recent Similar Reports:Less than 10 Resolution:Open
(it used to say "Recent Similar Reports: None", so something's happening at least, thanks to all of you guys)
corne-ac
commented
1 month ago FB13327641
how do i go about reporting this issue to apple? I am new to the apple space so not to sure where to go.
rolfbjarne
commented
1 month ago FB13327641
how do i go about reporting this issue to apple? I am new to the apple space so not to sure where to go.
You can either go to https://feedbackassistant.apple.com/ or use the "Feedback Assistant" app on your macOS device.
MichelePannacciTerex
commented
1 month ago I've submitted a DTS with Apple for this issue, let's see what they say.
Hi @rolfbjarne, did you have by any chances a patch diff for cctools? I ask because (I guess) we can compile it and install a modded version of strip in /usr/local/bin??
P.S. cctools-1010.6 appear to be 7 month old. Maybe it should work out of the box if is not the latest shipped with Xcode 16? edit: I'm running net9 rc2 and I have a strip error in relese build
MouratidisA
commented
1 month ago Working for me, following the steps below:
Install workload v8.0.402 using the terminal
sudo dotnet workload install maui-ios --version 8.0.402
Install Xcode 15.4 along with Xcode 16 on macOS Sequoia 15.0.1
- Download Xcode 15.4 from Xcode Releases
- Unzip the package and rename the Xcode do not launch it something like "Xcode_15.4"
- Move the application "Xcode_15.4" to Applications
Change the Xcode path to Xcode v15.4
JetBrains Rider β Settings βApple Platforms Xcode path (/Applications/Xcode_15.4.app)
Change the csproj of the maui solution
<PropertyGroup Condition="'$(Configuration)|$(TargetFramework)|$(Platform)'=='Debug|net8.0-ios|AnyCPU'">
<CreatePackage>false</CreatePackage>
<CodesignKey></CodesignKey>
<CodesignProvision></CodesignProvision>
<CodesignEntitlements>Platforms\iOS\Entitlements.plist</CodesignEntitlements>
<MtouchNoSymbolStrip>true</MtouchNoSymbolStrip>
<_ExportSymbolsExplicitly>false</_ExportSymbolsExplicitly>
<RuntimeIdentifier>ios-arm64</RuntimeIdentifier>
</PropertyGroup> macOS: Sequoia 15.0.1
JetBrains Rider: 2024.2.6
Xcode Version: 16.0 (16A242d)
Workload version: 8.0.402
maui-ios: SDK 8.0.400
ios: SDK 8.0.400
maui: SDK 8.0.400
android: SDK 8.0.400
activa
commented
1 month ago There's no need to install Xcode 15. Simply using the 402 payload is sufficient to successfully build apps. We released a new version of our app to the iOS store that was built on a Mac that only has Xcode 16.
rolfbjarne
commented
1 month ago I've submitted a DTS with Apple for this issue, let's see what they say.
Hi @rolfbjarne, did you have by any chances a patch diff for cctools? I ask because (I guess) we can compile it and install a modded version of strip in /usr/local/bin??
P.S. cctools-1010.6 appear to be 7 month old. Maybe it should work out of the box if is not the latest shipped with Xcode 16? edit: I'm running net9 rc2 and I have a strip error in relese build
See previous comment:
I think I figured out the problem with strip, and created a pull request: https://github.com/apple-oss-distributions/cctools/pull/2
FWIW I don't think you can replace /usr/bin/strip (at least not without disabling Apple's System Integrity Protection), but I think that executable only executes the one shipped with Xcode (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip), which you can replace.
MichelePannacciTerex
commented
1 month ago I've submitted a DTS with Apple for this issue, let's see what they say.
Hi @rolfbjarne, did you have by any chances a patch diff for cctools? I ask because (I guess) we can compile it and install a modded version of strip in /usr/local/bin?? P.S. cctools-1010.6 appear to be 7 month old. Maybe it should work out of the box if is not the latest shipped with Xcode 16? edit: I'm running net9 rc2 and I have a strip error in relese build
See previous comment:
I think I figured out the problem with strip, and created a pull request: apple-oss-distributions/cctools#2
FWIW I don't think you can replace
/usr/bin/strip(at least not without disabling Apple's System Integrity Protection), but I think that executable only executes the one shipped with Xcode (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip), which you can replace.
Hi and thanks for replying. The command can be placed where you like most, even inside the dotnet directory. What matter is your enviroment variable $PATH which can be manipulated to look first to a custom path so when you invoke strip, the first one will be used:
echo $PATH /usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/Library/Apple/usr/bin:/usr/local/share/dotnet:~/.dotnet/tools:/Library/Frameworks/Mono.framework/Versions/Current/Commands
As you can see, by default, /usr/local/bin is already the first path in $PATH, and is not protected by SIP. That unless a full path (e.g. ../usr/bin/strip) is given by the microsoft build tool, which in the case it would ruin the whole thing. Anyway it can than be used from a sh script and or Terminal. Note that dotnet is the last...but can be changed...
I'll let you know if I'll be able to compile your fixes.
MichelePannacciTerex
commented
1 month ago Hi @rolfbjarne I succeded, but to build a fixed "strip" llvm must be installed. Steps I made (if someone is intrested in):
decompress it and rename it just "llvm". After that create /usr/local/opt directory (will require elevated privileges). Copy llvm to /usr/local/opt/. Be aware that you need to include the new toolchain in your bash profile otherwise Xcode will not find it, or edit the cctools source code to include needed headers where it complains.
dowload https://github.com/apple-oss-distributions/cctools/archive/refs/tags/cctools-1010.6.tar.gz and decompress it.
create a directory named "mybin" inside it (cctools-cctools-1010.6/mybin).
patch ../cctools-cctools-1010.6/misc/strip.c as suggested by @rolfbjarne: after line 3857 (after new_ext_strsize += len;) insert:
if ((n_type & N_TYPE) == N_INDR && n_value != 0) {
len = strlen(strings + n_value) + 1;
new_ext_strsize += len;
}compile using terminal:
cd path/to/cctools-cctools-1010.6
then
xcodebuild -scheme strip -configuration Release ARCHS=arm64 ONLY_ACTIVE_ARCH=YES CONFIGURATION_BUILD_DIR=./mybin
Now copy path/to/cctools-cctools-1010.6/mybin/strip to /usr/local/bin/ (you may need to create the bin directory).
It will work now? No because as feared, the dotnet toolchain expect "strip" to be inside /Application/xcode/......./usr/bin/. and the enviroment variable $PATH is totally ignored (why??). To force the use of the new /usr/local/bin/strip you have to edit "Executable" in the following file (be aware that I'm using net9 rc2):
/usr/local/share/dotnet/packs/Microsoft.iOS.Sdk.net9.0_18.0/18.0.9600-net9-rc2/tools/msbuild/iOS/Xamarin.Share.targets
from:
<!-- strip the debug symbols from the executable -->
<SymbolStrip
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
Executable="$(_AppContainerDir)%(_NativeStripItems.Identity)"
Kind="%(_NativeStripItems.Kind)"
MaxDegreeOfParallelism="$(SymbolStripMaxDegreeOfParallelism)"
SymbolFile="%(_NativeStripItems.SymbolFile)"
/>
to:
<!-- strip the debug symbols from the executable -->
<SymbolStrip
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
Executable="/usr/local/bin/strip"
Kind="%(_NativeStripItems.Kind)"
MaxDegreeOfParallelism="$(SymbolStripMaxDegreeOfParallelism)"
SymbolFile="%(_NativeStripItems.SymbolFile)"
/>Finally, I can produce the smallest binary possible in Release mode using net9 + Xcode 16 on macOS 15.0.1 directly on my devices (which is working).
Final considerations: the above is a a proof of concept that we don't have to wait months Apple for a fix, but maybe we can include a precompiled-fixed copy of strip directly in the dotnet toolchain, or let the user using a different binary.
tipa
commented
1 month ago @MichelePannacciTerex tried to follow your guide because _ExportSymbolsExplicitly=false workaround appears to increase my app size significantly**. Unfortunately, I keep getting build errors when running the xcodebuild command:
CompileC /var/root/Library/Developer/Xcode/DerivedData/cctools-eimbnqwaggselfebxrnoxedwvclu/Build/Intermediates.noindex/cctools.build/Release/stuff.build/Objects-normal/arm64/hppa.o /Users/me/Downloads/cctools-cctools-1010.6/libstuff/hppa.c normal arm64 c com.apple.compilers.llvm.clang.1_0.compiler (in target 'stuff' from project 'cctools')
cd /Users/me/Downloads/cctools-cctools-1010.6
Using response file: /var/root/Library/Developer/Xcode/DerivedData/cctools-eimbnqwaggselfebxrnoxedwvclu/Build/Intermediates.noindex/cctools.build/Release/stuff.build/Objects-normal/arm64/7187679823f38a2a940e0043cdf9d637-common-args.resp
/Applications/Xcode-16.0.0.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x c -ivfsstatcache /var/root/Library/Developer/Xcode/DerivedData/SDKStatCaches.noindex/macosx15.0-24A336-c29e4adea30bffe86623e75b31a19d2e.sdkstatcache -fmessage-length\=151 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit\=0 -fcolor-diagnostics -Wno-trigraphs -Wno-missing-field-initializers -Wno-missing-prototypes -Werror\=return-type -Wdocumentation -Wunreachable-code -Werror\=deprecated-objc-isa-usage -Werror\=objc-root-class -Wno-missing-braces -Wparentheses -Wswitch -Wunused-function -Wno-unused-label -Wno-unused-parameter -Wunused-variable -Wunused-value -Wempty-body -Wuninitialized -Wconditional-uninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion -Wconstant-conversion -Wint-conversion -Wbool-conversion -Wenum-conversion -Wno-float-conversion -Wnon-literal-null-conversion -Wobjc-literal-conversion -Wshorten-64-to-32 -Wpointer-sign -Wno-newline-eof -Wno-implicit-fallthrough -fstrict-aliasing -Wdeprecated-declarations -Wno-sign-conversion -Winfinite-recursion -Wcomma -Wblock-capture-autoreleasing -Wstrict-prototypes -Wno-semicolon-before-method-body -Wunguarded-availability -Wno-ambiguous-macro -Wformat-nonliteral @/var/root/Library/Developer/Xcode/DerivedData/cctools-eimbnqwaggselfebxrnoxedwvclu/Build/Intermediates.noindex/cctools.build/Release/stuff.build/Objects-normal/arm64/7187679823f38a2a940e0043cdf9d637-common-args.resp -MMD -MT dependencies -MF /var/root/Library/Developer/Xcode/DerivedData/cctools-eimbnqwaggselfebxrnoxedwvclu/Build/Intermediates.noindex/cctools.build/Release/stuff.build/Objects-normal/arm64/hppa.d --serialize-diagnostics /var/root/Library/Developer/Xcode/DerivedData/cctools-eimbnqwaggselfebxrnoxedwvclu/Build/Intermediates.noindex/cctools.build/Release/stuff.build/Objects-normal/arm64/hppa.dia -c /Users/me/Downloads/cctools-cctools-1010.6/libstuff/hppa.c -o /var/root/Library/Developer/Xcode/DerivedData/cctools-eimbnqwaggselfebxrnoxedwvclu/Build/Intermediates.noindex/cctools.build/Release/stuff.build/Objects-normal/arm64/hppa.o
warning: Run script build phase 'Run Script' will be run during every build because it does not specify any outputs. To address this issue, either add output dependencies to the script phase, or configure it to run in every build by unchecking "Based on dependency analysis" in the script phase. (in target 'strip' from project 'cctools')
** BUILD FAILED **
The following build commands failed:
CompileC /var/root/Library/Developer/Xcode/DerivedData/cctools-eimbnqwaggselfebxrnoxedwvclu/Build/Intermediates.noindex/cctools.build/Release/stuff.build/Objects-normal/arm64/reloc.o /Users/me/Downloads/cctools-cctools-1010.6/libstuff/reloc.c normal arm64 c com.apple.compilers.llvm.clang.1_0.compiler (in target 'stuff' from project 'cctools')
CompileC /var/root/Library/Developer/Xcode/DerivedData/cctools-eimbnqwaggselfebxrnoxedwvclu/Build/Intermediates.noindex/cctools.build/Release/stuff.build/Objects-normal/arm64/lto.o /Users/me/Downloads/cctools-cctools-1010.6/libstuff/lto.c normal arm64 c com.apple.compilers.llvm.clang.1_0.compiler (in target 'stuff' from project 'cctools')** without Sentry and without _ExportSymbolsExplicitly=false, my app's install size is reported by TestFlight with 23.6 MB. With Sentry and with _ExportSymbolsExplicitly=false, it is reported as 43.5 MB
davidchieregato
commented
1 month ago @MichelePannacciTerex tried to follow your guide because
_ExportSymbolsExplicitly=falseworkaround appears to increase my app size significantly**. Unfortunately, I keep getting build errors when running thexcodebuildcommand:CompileC /var/root/Library/Developer/Xcode/DerivedData/cctools-eimbnqwaggselfebxrnoxedwvclu/Build/Intermediates.noindex/cctools.build/Release/stuff.build/Objects-normal/arm64/hppa.o /Users/me/Downloads/cctools-cctools-1010.6/libstuff/hppa.c normal arm64 c com.apple.compilers.llvm.clang.1_0.compiler (in target 'stuff' from project 'cctools') cd /Users/me/Downloads/cctools-cctools-1010.6 Using response file: /var/root/Library/Developer/Xcode/DerivedData/cctools-eimbnqwaggselfebxrnoxedwvclu/Build/Intermediates.noindex/cctools.build/Release/stuff.build/Objects-normal/arm64/7187679823f38a2a940e0043cdf9d637-common-args.resp /Applications/Xcode-16.0.0.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x c -ivfsstatcache /var/root/Library/Developer/Xcode/DerivedData/SDKStatCaches.noindex/macosx15.0-24A336-c29e4adea30bffe86623e75b31a19d2e.sdkstatcache -fmessage-length\=151 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit\=0 -fcolor-diagnostics -Wno-trigraphs -Wno-missing-field-initializers -Wno-missing-prototypes -Werror\=return-type -Wdocumentation -Wunreachable-code -Werror\=deprecated-objc-isa-usage -Werror\=objc-root-class -Wno-missing-braces -Wparentheses -Wswitch -Wunused-function -Wno-unused-label -Wno-unused-parameter -Wunused-variable -Wunused-value -Wempty-body -Wuninitialized -Wconditional-uninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion -Wconstant-conversion -Wint-conversion -Wbool-conversion -Wenum-conversion -Wno-float-conversion -Wnon-literal-null-conversion -Wobjc-literal-conversion -Wshorten-64-to-32 -Wpointer-sign -Wno-newline-eof -Wno-implicit-fallthrough -fstrict-aliasing -Wdeprecated-declarations -Wno-sign-conversion -Winfinite-recursion -Wcomma -Wblock-capture-autoreleasing -Wstrict-prototypes -Wno-semicolon-before-method-body -Wunguarded-availability -Wno-ambiguous-macro -Wformat-nonliteral @/var/root/Library/Developer/Xcode/DerivedData/cctools-eimbnqwaggselfebxrnoxedwvclu/Build/Intermediates.noindex/cctools.build/Release/stuff.build/Objects-normal/arm64/7187679823f38a2a940e0043cdf9d637-common-args.resp -MMD -MT dependencies -MF /var/root/Library/Developer/Xcode/DerivedData/cctools-eimbnqwaggselfebxrnoxedwvclu/Build/Intermediates.noindex/cctools.build/Release/stuff.build/Objects-normal/arm64/hppa.d --serialize-diagnostics /var/root/Library/Developer/Xcode/DerivedData/cctools-eimbnqwaggselfebxrnoxedwvclu/Build/Intermediates.noindex/cctools.build/Release/stuff.build/Objects-normal/arm64/hppa.dia -c /Users/me/Downloads/cctools-cctools-1010.6/libstuff/hppa.c -o /var/root/Library/Developer/Xcode/DerivedData/cctools-eimbnqwaggselfebxrnoxedwvclu/Build/Intermediates.noindex/cctools.build/Release/stuff.build/Objects-normal/arm64/hppa.o warning: Run script build phase 'Run Script' will be run during every build because it does not specify any outputs. To address this issue, either add output dependencies to the script phase, or configure it to run in every build by unchecking "Based on dependency analysis" in the script phase. (in target 'strip' from project 'cctools') ** BUILD FAILED ** The following build commands failed: CompileC /var/root/Library/Developer/Xcode/DerivedData/cctools-eimbnqwaggselfebxrnoxedwvclu/Build/Intermediates.noindex/cctools.build/Release/stuff.build/Objects-normal/arm64/reloc.o /Users/me/Downloads/cctools-cctools-1010.6/libstuff/reloc.c normal arm64 c com.apple.compilers.llvm.clang.1_0.compiler (in target 'stuff' from project 'cctools') CompileC /var/root/Library/Developer/Xcode/DerivedData/cctools-eimbnqwaggselfebxrnoxedwvclu/Build/Intermediates.noindex/cctools.build/Release/stuff.build/Objects-normal/arm64/lto.o /Users/me/Downloads/cctools-cctools-1010.6/libstuff/lto.c normal arm64 c com.apple.compilers.llvm.clang.1_0.compiler (in target 'stuff' from project 'cctools')** without Sentry and without
_ExportSymbolsExplicitly=false, my app's install size is reported by TestFlight with 23.6 MB. With Sentry and with_ExportSymbolsExplicitly=false, it is reported as 43.5 MB
I have the same issue
MichelePannacciTerex
commented
1 month ago @MichelePannacciTerex tried to follow your guide because
_ExportSymbolsExplicitly=falseworkaround appears to increase my app size significantly**. Unfortunately, I keep getting build errors when running thexcodebuildcommand:CompileC /var/root/Library/Developer/Xcode/DerivedData/cctools-eimbnqwaggselfebxrnoxedwvclu/Build/Intermediates.noindex/cctools.build/Release/stuff.build/Objects-normal/arm64/hppa.o /Users/me/Downloads/cctools-cctools-1010.6/libstuff/hppa.c normal arm64 c com.apple.compilers.llvm.clang.1_0.compiler (in target 'stuff' from project 'cctools') cd /Users/me/Downloads/cctools-cctools-1010.6 Using response file: /var/root/Library/Developer/Xcode/DerivedData/cctools-eimbnqwaggselfebxrnoxedwvclu/Build/Intermediates.noindex/cctools.build/Release/stuff.build/Objects-normal/arm64/7187679823f38a2a940e0043cdf9d637-common-args.resp /Applications/Xcode-16.0.0.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x c -ivfsstatcache /var/root/Library/Developer/Xcode/DerivedData/SDKStatCaches.noindex/macosx15.0-24A336-c29e4adea30bffe86623e75b31a19d2e.sdkstatcache -fmessage-length\=151 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit\=0 -fcolor-diagnostics -Wno-trigraphs -Wno-missing-field-initializers -Wno-missing-prototypes -Werror\=return-type -Wdocumentation -Wunreachable-code -Werror\=deprecated-objc-isa-usage -Werror\=objc-root-class -Wno-missing-braces -Wparentheses -Wswitch -Wunused-function -Wno-unused-label -Wno-unused-parameter -Wunused-variable -Wunused-value -Wempty-body -Wuninitialized -Wconditional-uninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion -Wconstant-conversion -Wint-conversion -Wbool-conversion -Wenum-conversion -Wno-float-conversion -Wnon-literal-null-conversion -Wobjc-literal-conversion -Wshorten-64-to-32 -Wpointer-sign -Wno-newline-eof -Wno-implicit-fallthrough -fstrict-aliasing -Wdeprecated-declarations -Wno-sign-conversion -Winfinite-recursion -Wcomma -Wblock-capture-autoreleasing -Wstrict-prototypes -Wno-semicolon-before-method-body -Wunguarded-availability -Wno-ambiguous-macro -Wformat-nonliteral @/var/root/Library/Developer/Xcode/DerivedData/cctools-eimbnqwaggselfebxrnoxedwvclu/Build/Intermediates.noindex/cctools.build/Release/stuff.build/Objects-normal/arm64/7187679823f38a2a940e0043cdf9d637-common-args.resp -MMD -MT dependencies -MF /var/root/Library/Developer/Xcode/DerivedData/cctools-eimbnqwaggselfebxrnoxedwvclu/Build/Intermediates.noindex/cctools.build/Release/stuff.build/Objects-normal/arm64/hppa.d --serialize-diagnostics /var/root/Library/Developer/Xcode/DerivedData/cctools-eimbnqwaggselfebxrnoxedwvclu/Build/Intermediates.noindex/cctools.build/Release/stuff.build/Objects-normal/arm64/hppa.dia -c /Users/me/Downloads/cctools-cctools-1010.6/libstuff/hppa.c -o /var/root/Library/Developer/Xcode/DerivedData/cctools-eimbnqwaggselfebxrnoxedwvclu/Build/Intermediates.noindex/cctools.build/Release/stuff.build/Objects-normal/arm64/hppa.o warning: Run script build phase 'Run Script' will be run during every build because it does not specify any outputs. To address this issue, either add output dependencies to the script phase, or configure it to run in every build by unchecking "Based on dependency analysis" in the script phase. (in target 'strip' from project 'cctools') ** BUILD FAILED ** The following build commands failed: CompileC /var/root/Library/Developer/Xcode/DerivedData/cctools-eimbnqwaggselfebxrnoxedwvclu/Build/Intermediates.noindex/cctools.build/Release/stuff.build/Objects-normal/arm64/reloc.o /Users/me/Downloads/cctools-cctools-1010.6/libstuff/reloc.c normal arm64 c com.apple.compilers.llvm.clang.1_0.compiler (in target 'stuff' from project 'cctools') CompileC /var/root/Library/Developer/Xcode/DerivedData/cctools-eimbnqwaggselfebxrnoxedwvclu/Build/Intermediates.noindex/cctools.build/Release/stuff.build/Objects-normal/arm64/lto.o /Users/me/Downloads/cctools-cctools-1010.6/libstuff/lto.c normal arm64 c com.apple.compilers.llvm.clang.1_0.compiler (in target 'stuff' from project 'cctools')** without Sentry and without
_ExportSymbolsExplicitly=false, my app's install size is reported by TestFlight with 23.6 MB. With Sentry and with_ExportSymbolsExplicitly=false, it is reported as 43.5 MB
Hi, I want to clarify that I don't want to encourage peoples to modify/ruin their toolchains, my point was only that maybe microsoft guys can build a fixed version and ship it in the net toolchain for maui. Could be right, could be wrong. After that you surely missing some headers as your enviremont variables to include LLVM aren't set at all. You can have anyway a build by edit those files manually, and you can see where it complains by running cctools in Xcode with the strip target selected. They should be:
Open /cctools-cctools-1010.6/libstuff/reloc.c delete line 166 and 167 as you dont have 'CPU_TYPE_RISCV32' defined. You are compiling for arm cpu, so it's safe:
case CPU_TYPE_RISCV32:
return(FALSE);Again, as you don't have the enviroment variable set to include llvm in $PATH nor the include path:
Open /cctools-cctools-1010.6/libstuff/lto.c
edit lto include from:
#include <llvm-c/lto.h>
to
#include "/usr/local/opt/llvm/include/llvm-c/lto.h" // or where ever you have llvm
I guess this should be enough, unless in your system other headers are missing.
EDIT modify strip.c is still needed :)
tipa
commented
1 month ago @MichelePannacciTerex Thanks so much for your repeated help. I did add LLVM to the path (or included the path the HEADER_SEARCH_PATHS) - but that caused a trillion of other errors (something in the sort of "int64_t not found"). It took me 2 hours until I just manually edited the #imports that weren't found and filled in the exact path on my machine. Also had to adjust an #import in a file somewhere in the llvm folder. But then it finally worked!
And I agree that perhaps this fix should be applied by Microsoft as it's probably rather unlikely that Apple fixes this on their own anytime soon...
MichelePannacciTerex
commented
1 month ago @MichelePannacciTerex Thanks so much for your repeated help. I did add LLVM to the path (or included the path the
HEADER_SEARCH_PATHS) - but that caused a trillion of other errors (something in the sort of "int64_t not found"). It took me 2 hours until I just manually edited the#importsthat weren't found and filled in the exact path on my machine. Also had to adjust an#importin a file somewhere in the llvm folder. But then it finally worked! And I agree that perhaps this fix should be applied by Microsoft as it's probably rather unlikely that Apple fixes this on their own anytime soon...
Glad it worked, but do not thanks me. Thanks @rolfbjarne for the real fix
tipa
commented
1 month ago @MichelePannacciTerex I did some tests with the self-compiled strip (and with a project that wouldn't need the workaround). For some reasons, it appears that it results in larger .ipa bundles than the original strip file:
Now I'm lost again... π
MichelePannacciTerex
commented
1 month ago @MichelePannacciTerex I did some tests with the self-compiled strip (and with a project that wouldn't need the workaround). For some reasons, it appears that it results in larger
.ipabundles than the originalstripfile:
- with old strip: 4.4 MB
- with new strip: 5.6 MB
Now I'm lost again... π
Hi, I'm not sure I can help further, mine goes from almost 300 MB to 24 MB. Did you have the Interpreter enabled?
tipa
commented
1 month ago Tried with a blank dotnet new ios project and only removed TrimMode=full and added PublishAot=true. The old strip generates a 1.1 MB ipa, the self-compiled on a 1.6 MB ipa file. Are you seeing different results? Does it matter on what machine I use the file? I compiled it on a macOS 15 machine but use it on macOS 14
MichelePannacciTerex
commented
1 month ago Tried with a blank
dotnet new iosproject and only removedTrimMode=fulland addedPublishAot=true. The old strip generates a 1.1 MB ipa, the self-compiled on a 1.6 MB ipa file. Are you seeing different results? Does it matter on what machine I use the file? I compiled it on a macOS 15 machine but use it on macOS 14
Hi, lastest cctools minimum deployment target is macOS 14.0, but this has nothing to do with anything as otherwise it will just crash. Unfortunately I did not make any comparisons about sizing because I've just updated only one maui project to the net9 toolchain (waiting for the official final release), or to be more precise the ipa is a little bigger than it used to be if compiled against net8; so considering that I updated all the packages, and that iOS SDK is different... I didn't ask myself too many questions (yet) because I just thought it was a lot better than nothing (error code 139). I'm not even sure if Xcode 16 provides a version of cctools that matches the latest commit on their repository, but as it's in a working state it's also strange to me of such difference on the same project (and targeting the same device). I'll leave my compiled binary here if you want to try it, although I don't see how it could be any better. One final consideration is that the fix provides more space for the processed indirect symbols (a bigger size then?), so I'm not completely sure the old strip is better, or at least not in all scenarios your app can jump in. strip.zip
npostma
commented
1 month ago I did a full macOS reinstall, and now Iβm encountering this issue as well. Whatβs the best workaround available for publication right now? Iβm able to build and test a debug build, but I run into this error when trying to create a release build.
Build command:
/usr/local/share/dotnet/dotnet publish "/<PATH>/ActiveID/ActiveID.csproj" --configuration "Release" --framework "net8.0-ios" --output "bin/Release/net8.0-ios/publish"Error:
Optimizing assemblies for size may change the behavior of the app. Be sure to test after publishing. See: https://aka.ms/dotnet-illink
Optimizing assemblies for size. This process might take a while.
Tool xcrun execution finished (exit code = 139).
/usr/local/share/dotnet/packs/Microsoft.iOS.Sdk.net8.0_18.0/18.0.8303/tools/msbuild/iOS/Xamarin.Shared.targets(2848,3): error : strip exited with code 139 [/<PATH>/ActiveID/ActiveID.csproj::TargetFramework=net8.0-ios]
/usr/local/share/dotnet/packs/Microsoft.iOS.Sdk.net8.0_18.0/18.0.8303/tools/msbuild/iOS/Xamarin.Shared.targets(2848,3): error : [/<PATH>/ActiveID/ActiveID.csproj::TargetFramework=net8.0-ios]
Lucasian20
commented
1 month ago @rolfbjarne Feedback sent: https://feedbackassistant.apple.com/feedback/15529239 - I have referenced your pull-request
Any news on this? I have managed to successfully publish dotnet publish -f net8.0-ios with XCode 16 using _ExportSymbolsExplicitly=false luckily without app increasing in size
rolfbjarne
commented
1 month ago @rolfbjarne Feedback sent: feedbackassistant.apple.com/feedback/15529239 - I have referenced your pull-request
Any news on this? I have managed to successfully publish dotnet publish -f net8.0-ios with XCode 16 using _ExportSymbolsExplicitly=false luckily without app increasing in size
No, no news from Apple.
Lucasian20
commented
1 month ago @rolfbjarne Feedback sent: feedbackassistant.apple.com/feedback/15529239 - I have referenced your pull-request Any news on this? I have managed to successfully publish dotnet publish -f net8.0-ios with XCode 16 using _ExportSymbolsExplicitly=false luckily without app increasing in size
No, no news from Apple.
I don't think we should expect them to. I see your pull-request is a year old - did it suddenly fix itself last year, if so what changed?
rolfbjarne
commented
1 month ago @rolfbjarne Feedback sent: feedbackassistant.apple.com/feedback/15529239 - I have referenced your pull-request Any news on this? I have managed to successfully publish dotnet publish -f net8.0-ios with XCode 16 using _ExportSymbolsExplicitly=false luckily without app increasing in size
No, no news from Apple.
I don't think we should expect them to. I see your pull-request is a year old - did it suddenly fix itself last year, if so what changed?
They prioritize feedback tickets depending on how many duplicates a ticket has, which is why I've asked people who run into this to file feedback tickets with Apple.
The difference is exactly that: how many people are running into the bug (and are hopefully reporting it to Apple).
Please file a feedback ticket with Apple if you run into this issue
See this comment for more information: https://github.com/xamarin/xamarin-macios/issues/19157#issuecomment-2363300980
Steps to Reproduce
<PackageReference Include="Esri.ArcGISRuntime" Version="200.2.0" />Note that if you skip step 2, there is no issue. Something about this library causes the stripper to crash.
Workaround
Add
This is quite a showstopper for us, as this prevents any of our users from using our nuget packages. We are fairly certain the issue is connected to the XCode 15 upgrade.
Expected Behavior
App builds and deploys.
Actual Behavior
Crash in the stripper
Environment
VS Preview 17.8 p3+remote macos host, or just .NET 8 RC2 commandline on macos with XCode. We have reproduced on multiple machines, Windows and Mac.
Build Logs
1>/usr/bin/ditto /Users/mort5161/Library/Caches/Xamarin/mtbs/builds/MauiApp10/45615ce3ae59fa5d7b49616b08a491ce70088b1a274c6bd0fc1cb4b5a8be76d0/C:/Users/mort5161/.nuget/packages/esri.arcgisruntime.runtimes.ios/200.2.0/framework/ios-arm64/native/ArcGIS-arm64.framework/ /Users/mort5161/Library/Caches/Xamarin/mtbs/builds/MauiApp10/45615ce3ae59fa5d7b49616b08a491ce70088b1a274c6bd0fc1cb4b5a8be76d0/bin/Debug/net8.0-ios/ios-arm64/device-builds/iphone11.6-16.7/MauiApp10.app/Frameworks/ArcGIS-arm64.framework --arch arm64 1>/usr/bin/ditto /Users/mort5161/Library/Caches/Xamarin/mtbs/builds/MauiApp10/45615ce3ae59fa5d7b49616b08a491ce70088b1a274c6bd0fc1cb4b5a8be76d0/C:/Users/mort5161/.nuget/packages/esri.arcgisruntime.runtimes.ios/200.2.0/framework/ios-arm64/native/Runtimecore.framework/ /Users/mort5161/Library/Caches/Xamarin/mtbs/builds/MauiApp10/45615ce3ae59fa5d7b49616b08a491ce70088b1a274c6bd0fc1cb4b5a8be76d0/bin/Debug/net8.0-ios/ios-arm64/device-builds/iphone11.6-16.7/MauiApp10.app/Frameworks/Runtimecore.framework --arch arm64 1>Tool xcrun execution finished (exit code = 139). 1>C:\Program Files\dotnet\packs\Microsoft.iOS.Sdk\16.4.8968-net8-rc2\tools\msbuild\iOS\Xamarin.Shared.targets(2750,3): error : strip exited with code 139 1>C:\Program Files\dotnet\packs\Microsoft.iOS.Sdk\16.4.8968-net8-rc2\tools\msbuild\iOS\Xamarin.Shared.targets(2750,3): error :
Example Project (If Possible)
Repro project. Just try and deploy to an iPhone device: MauiArcGISApp1.zip