When I tried to create IPA file using Distribute APP option. It gave "IPA processing failed" error.
I have checked logs file: IDEDistribution.standard.log file.
2019-08-06 18:36:52 +0000 warning: Configuration issue: platform
iPhoneSimulator.platform doesn't have any non-simulator SDKs; ignoring
it Scanning IPA... 2019-08-06 18:36:52 +0000 Assertion failed:
Expected 4 archs in otool output:
/var/folders/4t/rpjk7pd55t16jfrd32y98gf0lb2t68/T/IDEDistributionOptionThinning.~~~a4cZJc/Payload/demo.app/Frameworks/AppAuth.framework/AppAuth:
Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags MH_MAGIC_64 X86_64 ALL 0x00 DYLIB 23
3680 NOUNDEFS DYLDLINK TWOLEVEL NO_REEXPORTED_DYLIBS Load command 0
I faced same issue.I have fix this issue used this script.
Please follow the same steps.
Build Phases -> plus button -> to create New Run Script Phase
APP_PATH="${TARGET_BUILD_DIR}/${WRAPPER_NAME}"
find "$APP_PATH" -name '*.framework' -type d | while read -r FRAMEWORK
do
FRAMEWORK_EXECUTABLE_NAME=$(defaults read "$FRAMEWORK/Info.plist" CFBundleExecutable)
FRAMEWORK_EXECUTABLE_PATH="$FRAMEWORK/$FRAMEWORK_EXECUTABLE_NAME"
echo "Executable is $FRAMEWORK_EXECUTABLE_PATH"
echo $(lipo -info "$FRAMEWORK_EXECUTABLE_PATH")
FRAMEWORK_TMP_PATH="$FRAMEWORK_EXECUTABLE_PATH-tmp"
case "${TARGET_BUILD_DIR}" in
*"iphonesimulator")
echo "No need to remove archs"
;;
*)
if $(lipo "$FRAMEWORK_EXECUTABLE_PATH" -verify_arch "i386") ; then
lipo -output "$FRAMEWORK_TMP_PATH" -remove "i386" "$FRAMEWORK_EXECUTABLE_PATH"
echo "i386 architecture removed"
rm "$FRAMEWORK_EXECUTABLE_PATH"
mv "$FRAMEWORK_TMP_PATH" "$FRAMEWORK_EXECUTABLE_PATH"
fi
if $(lipo "$FRAMEWORK_EXECUTABLE_PATH" -verify_arch "x86_64") ; then
lipo -output "$FRAMEWORK_TMP_PATH" -remove "x86_64" "$FRAMEWORK_EXECUTABLE_PATH"
echo "x86_64 architecture removed"
rm "$FRAMEWORK_EXECUTABLE_PATH"
mv "$FRAMEWORK_TMP_PATH" "$FRAMEWORK_EXECUTABLE_PATH"
fi
;;
esac
echo "Completed for executable $FRAMEWORK_EXECUTABLE_PATH"
echo $(lipo -info "$FRAMEWORK_EXECUTABLE_PATH")
done
1.uncheck "Rebuild from bitcode",
2.click next fast fast fast. (speed is also important.)
if not , it will show IPA processing failed.
You should check the Embed Frameworks under Xcode > build phases.
If your framework is introduced here, you can't use i386\x86_64 in your framework. Because the Embed Frameworks are copied to the application. To control the size of the application, the frameworks in the Embed Frameworks are required to be the most streamlined.
You can use Link Binary With Libraries to introduce your framework, as described here: https://github.com/Carthage/Carthage/issues/1046
Note that you need to add a new Run Script and add your framework to it, or it will crash.
To solve similar problem on my end I used the following:
In app's target I went to the Build Phases
After the Embed Frameworks and Embed App Extensions sections I've added Run script with the following script:
APP_PATH="${TARGET_BUILD_DIR}/${WRAPPER_NAME}"
# This script loops through the frameworks embedded in the application and
# removes unused architectures.
find "$APP_PATH" -name '*.framework' -type d | while read -r FRAMEWORK
do
FRAMEWORK_EXECUTABLE_NAME=$(defaults read "$FRAMEWORK/Info.plist" CFBundleExecutable)
FRAMEWORK_EXECUTABLE_PATH="$FRAMEWORK/$FRAMEWORK_EXECUTABLE_NAME"
echo "Executable is $FRAMEWORK_EXECUTABLE_PATH"
EXTRACTED_ARCHS=()
for ARCH in $ARCHS
do
echo "Extracting $ARCH from $FRAMEWORK_EXECUTABLE_NAME"
lipo -extract "$ARCH" "$FRAMEWORK_EXECUTABLE_PATH" -o "$FRAMEWORK_EXECUTABLE_PATH-$ARCH"
EXTRACTED_ARCHS+=("$FRAMEWORK_EXECUTABLE_PATH-$ARCH")
done
echo "Merging extracted architectures: ${ARCHS}"
lipo -o "$FRAMEWORK_EXECUTABLE_PATH-merged" -create "${EXTRACTED_ARCHS[#]}"
rm "${EXTRACTED_ARCHS[#]}"
echo "Replacing original executable with thinned version"
rm "$FRAMEWORK_EXECUTABLE_PATH"
mv "$FRAMEWORK_EXECUTABLE_PATH-merged" "$FRAMEWORK_EXECUTABLE_PATH"
done
The script I took from here: https://medium.com/#maximbilan/ios-submission-unsupported-architectures-issues-733917a98cc3, credits goes to Daniel Kennet!
Also, be aware that this script could also cause compilation errors. In such case, here's the solution: Errors building Xcode Project after adding in Run Script fatal error: lipo: input file
On my end I also noticed that I have to turn off this script when compiling app locally (on development devices/simulator)
Hope that helps!
It seems that a dynamic library with i386 or x86_64 architecture is not allowed when archive in Xcode 11. And I fixed it by removing those architectures from the mentioned frameworks
I had to uncheck "Rebuild from bitcode"
For those who try with M1 Chip (Silicon)
Quit Xcode completely (Close and Quit From the Menu Bar) and remove existing archived one.
Go to finder -> Applications
Right Click on Xcode and select "Get Info"
Check Rosetta
Try again opening Xcode
We've solved this problem by setting Always Embed Swift Standard Libraries to NO in all frameworks, that are being used in our app.
I had to select "Do not embed" in Frameworks to solve this
Having Bitcode enabled caused the issue in my case. Go to
Build Settings -> Enable Bitcode and set it to NO.
Try archiving again and it should work.
In my case, app thinning was failing and the reason was my internal framework was depending Alamofire and it's binary was embedding and signing. Changing it's Embed option from Embed & Sign -> Do Not Embed solved my issue immediately.
In my opinion, all logic behind this issue is keep app bundle size lower as much as Apple can but embedding your frameworks increase this size. I think that's all App Thinning complains about. So, the general solution to this issue, check every external frameworks that can increase your app bundle. Especially, if you're using Carthage.
I found issue with SDWebImageMapKit framework available with SDWebImage. I just removed it and got success.
My issue was that I had a single embedded binary framework.
I removed it from the project to update it. Which caused Xcode to delete the embed frameworks build phase (because there were no more frameworks to embed).
After adding the new version of our framework, the embed binaries phase was at the bottom of the build phase order. Which ended up being the reason it was failing.
I had to re-order embed frameworks before my run script to fix the problem.
I haven't updated my cocoapods for a while, fixed it by updating and re-installing the pods.
sudo gem install cocoapods
pod update
pod deintegrate
pod install
My solution was to set all frameworks dependencies to "Do Not Embed"
Open Terminal
Open your project drag path of respective framework to Terminal
For example.
cd /Users/xxxxx/Desktop/MyProject/ABC.framework
Set your Framework name in below command and run
lipo -remove i386 ABC -o ABC && lipo -remove x86_64 ABC -o ABC
Related
I am trying to use re-sharper command line tools. But I get an error which is highlighted . I am using only one solution. What could be the issue?
here is my command and responses
PS D:\JERPOS\Tools\ResharperCommandLine> .\InspectCode.exe -o="D:\temp
\Results.xml" -d --swea -x=EtherealCode.ReSpeller "D:\JERPOS\Code\POS Client\Jer.Pos.ClientStartup.sln"
JetBrains Inspect Code 2016.1.2
Running in 64-bit mode, .NET runtime 4.0.30319.34209 under Microsoft Windows NT 6.2.9200.0
**Specify only one solution file**
Usage: InspectCode.exe [options] [project file]
Show help: InspectCode.exe --help
Enabled solution-wide analysis according to Inspect Code command line Setting.
You probably worked this out by now but I'm pretty sure it's due to the space in the path (even though it's quoted). I had a similar problem and fixed it by creating a symlink to the directory without a space in the name.
I had this issue with the ReSharper Tools downloaded with nuget. The problem was the -o command, which it somehow failed to recognize.
changing -o to --output fixed it:
inspectcode.exe YourSolution.sln -output="D:\temp\Results.xml"
I'm starter Z3 so my question may be too basic.
But If you let me know some information for my question, I'm very happy.
I searched before history in this site.
But I couldn't get detailed information for me. ( because maybe..my question is too basic..)
[using Visual C++]
1) First of all, I downloaded "z3 4.3.0 for window" at codePlex site.
But this file doesn't have example file(test_capi.c).
So I got "z3-89c1785b73225a1b363c0e485f854613121b70a7.zip" for example file.
( I cannot remember what I can get... :( )
I succeeded compiling python file as codeplex site quide.
But I cannot compile test_capi.c using Visual C++.
I also added "test_capi.c" at "z3 4.3.0 for window" folder but I cannot also compile.
Lastly, I just tried using "test_capi.vcxproj" of "z3-src-4.1.1" and this is succeeded.
I cannot understand.
If i want to test "my file", what file is needed at "z3 4.3.0 for window"?
Or
Do I have to use only "z3 4.1.1" for visual c++ and add "my file" at some location of "z3 4.1.1"? ( All files of Z3 4.1.1 is needed?? AND what is the Some location?)
I read other some comment - "Z3 4.3.0" is simplified.
I understood this comment that I can use only "z3 4.3.0" and test successfully.
But as i told you, I cannot compile.
Please give me some information..
[using gcc in ubuntu]
First of all, I downloaded "z3-4.3.2.07d56bdc705c-x86-ubuntu-12.04.zip" from codeplex site.
Because I tried git command for getting source code but i cannot find source code.
( I also don't know the reason..)
Anyway... "z3-4.3.2.07d56bdc705c-x86-ubuntu-12.04.zip" doesn't have any example file and only bin & include folder is existed.
So I also used "z3 4.1.1" but i cannot compile using below command.
gcc -fopenmp -o test_capi -I ../../Include -L ../../lib test_capi.c -lz3-gmp
Error is "cannot find -lz3-gmp."
In some comment, I found "use "sudo install"" but i don't know how i can install lz3.
(Of course only "sudo install" doesn't work and "sudo apt-get install z3" also doesn't work...)
For compiling "test_capi.c" using gcc, could you explain in detail..?
I'm confused many kinds of guide but i couldn't get basic information for me.
Thank you in advance and I hope to get information...even if my question is too basic..
First, you should use only one version of the source code. Version 4.1.1 is very old and newer versions do not come with test_capi.vcxproj anymore, instead everything is done via the Makefile. For the very latest version please use the unstable branch (e.g., by selecting unstable here and then clicking download.)
The examples can be compiled by calling nmake examples (on Windows) or make examples (on Linux) in the build directory. The makefile has a target called _ex_c_example which shows how to call the compiler for the C example. The various variables that this target uses are defined in build/config.mk. Note that these variables are set to different values on Windows and Linux (this file is produced by python scripts/mk_make.py).
The git command on many Linux distributions is not compatible with the codeplex git server (for a fix see here), but of course this is not necessary if you download the source code from the webpage directly.
We are avid Eclipse fans -- it is fantastic! But we have about 40 c++ projects (and growing), and building all of these projects, when all projects are up-to-date, takes about half a minute (total). If I were to simply create a bash script that executed "make all" on all 40 projects, it would execute in way less than a second.
Eclipse seems to want to run a test for the proper tools each time by executing:
g++ -E -P -v -dD /myfolder/.metada/.plugins/org.eclipse.cdt.make.core/specs.cpp
where specs.cpp is an empty file. This step seems to be taking most of the build time.
Any insight here from anyone? Any way to tell Eclipse to trust the tools?
I would suggest you to experiment with C/C++ Build Discovery options page of your projects properties. The first thing that I would try is to turn off "Enable generate scanner info command" option.
I am very new to InstallShield and have inherited a InstallScript project. I have mostly figured out my way around and fixed most of the problems. However, I wish to build this project automatically on our build server with each build of our product. I have this working fine. For some reason, though, I cannot get the version number to increase.
I am using the command:
IsCmdBld.exe
-P <.ism location>
-L <some_path_variable>=<some_value>
-L <some_path_variable2>=<some_value2>
This works.
However, adding -y 1.2.3, -y "1.2.3", -z Version=1.2.3, -z Version="1.2.3", -z "Version=1.2.3", -z ProductVersion=1.2.3, -z ProductVersion="1.2.3", or -z "ProductVersion=1.2.3". does not work.
When I say that it doesn't work, I mean that using the resulting installer does not attempt to do an upgrade like it would if I manually increased the Version string in the Product Properties table from inside InstallShield.
Is there something I am missing? I know I am not providing much to go on, just hoping someone has come across this problem before. Also, using the -c COMP switch does not work.
Any thoughts appreciated.
I believe IsCmdBld only supports passing ProductVersion properties for MSI projects, but not for InstallScript projects. I believe you need to do something like this prior to calling IsCmdBld:
set project = CreateObject("ISWiAuto15.ISWiProject")
project.OpenProject "C:\test.ism"
project.ProductVersion = "2.0.0"
project.CloseProject
set project = nothing
Alternatively you can save your project type in XML format and use an XPath / XPoke to update the ProductVersion in the Property table. The syntax is a little scary because of the DTD, but it can be done.
This is an old question but I was finally able to figure out how to make it work from the command line for me so I thought I would share it. I created a Path Variable (VersionNumber in the example below) in the project and set the product version to that path variable in the "General Information" section.
Then you can set it at the command line using the -l flag.
ISCmdBld.exe -p project.ism -l VersionNumber=1.1.0
Is there a commonly used approach for displaying 'how to get started' instructions to a user after a .deb installer has finished installing a package?
I need an approach that works for users working via a terminal as well as from a desktop environment.
Server admins will probably know to check for a README file but many others won't.
I'd suggest running the "tty" command from your postinstall script. That will tell you if you have a tty and are running as a terminal program. Once you know that you could either "more" a readme file if you're running in terminal mode or you could call "gnome-text-editor" if not. You might also want to put in some detection to check "/etc/lsb-release" so that you know what distribution your .deb is being installed on and which editors will be suitable.
I use the tty command like Benj suggested, but I use the dialog command to display post install chatter if its available on the system.
Try this command:
dialog --backtitle "All done" --title "Installation complete" --textbox /etc/passwd 0 0
... but replace /etc/passwd with your README of choice. Its a much nicer way to scroll through information.
After a bit of experimentation it looks like I can detect how the .deb package has been installed by checking the value of the DEBIAN_FRONTEND variable in the postint.sh script. When run from the desktop it contains the value 'gnome', but when run via dpkg from the command-line it isn't set, so something like this might work:
HELP_URL="http://mysite.com/help.html"
if [ "$DEBIAN_FRONTEND" = "gnome" ]; then
nohup gnome-www-browser $HELP_URL &
else
echo For help visit $HELP_URL
fi