I have following framework binaries:
Device.framework
Device.dSYM
Simulator_x86.framework
Simulator_arm.framework
I first create a fat binary from the 2 simulator files:
lipo -create
-output /Output/Simulator
/Simulator/Simulator_x86.framework
/Simulator/Simulator_arm.framework
Then I use xcodebuild to create xcframework like this:
xcodebuild -create-xcframework
-framework /Input/Device.framework
-debug-symbols /Input/Device.dSYM
-framework /Output/Simulator
-output Release/App.xcframework
In the resultant xcframework, some time the dSYM directory gets copied to ios-arm64 directory and sometimes to ios-arm64_x86_64-simulator which clearly seems to be some bug.
Earlier, I was copying the file manually so the issue was not there. Now, I am using a script to automate the complete process and some times the script fails because it doesn't find the dSym file at the specified folder.
Related
I have this project with multiple iOS targets. Each target has its own AppDelegate.h and AppDelegate.m which inherits from either AppDelegateBase or AppDelegateServiceBase. I am using Xcode 13.4.1 - the build works fine but archive fails. For Xcode 12.x, this works just fine.
The moment I try to archive, it resolves to wrong header from a different target but same name and naturally gives error because of difference in imports.
Any idea how to fix this?
I use xcodebuild -project client/Onyz.xcodeproj -scheme IQW -configuration DEBUG -sdk iphoneos15.5 archive … this gives me error as the path for a file referring to AppDelegate resolves to target IMW (which is the other target). Part of logs are below. Initially this problem was extending to build command as well, but changing from -target to -scheme fixed it. This pattern of failure holds across xcodebuild and Xcode but limited to 13 and above.
In file included from /Volumes/ZX_2TB_SSD/j1/workspace/Onyz/client/iOS/WebBrowserMenuViewController.m:19: In file included from /Volumes/ZX_2TB_SSD/j1/workspace/Onyz/client/iOS/Targets/IMW/AppDelegate.h:10: In file included from /Volumes/ZX_2TB_SSD/j1/workspace/Onyz/client/iOS/AppDelegateServiceBase.h:20: In file included from /Volumes/ZX_2TB_SSD/j1/workspace/Onyz/client/iOS/SDK/AdSupport/AotAdWindow.h:10: /Volumes/ZX_2TB_SSD/j1/workspace/Onyz/client/iOS/SDK/AdSupport/AotAdNetworkManager.h:13:9: fatal error: 'GoogleMobileAds/GoogleMobileAds.h' file not found #import <GoogleMobileAds/GoogleMobileAds.h>
On 2nd line - instead of IMW, it should be IQW and after that the rest of header resolution chain will change.
I have an Objective-C Xcode project. Previously, there were no test targets in this project. We added a Swift-based test target and a few basic tests. The project continues to build from the Xcode GUI just fine. However, building from the command line fails when trying to link the test target.
% xcodebuild -project Foo.xcodeproj -scheme Foo -configuration AdHoc -sdk iphoneos build
...output...
The following build commands failed:
Ld /Users/mluton/Library/Developer/Xcode/DerivedData/Foo-hkljicipwnivteazylcxtobonsbc/Build/Intermediates/Foo.build/AdHoc-iphoneos/FooTests.build/Objects-normal/armv7/FooTests normal armv7
Ld /Users/mluton/Library/Developer/Xcode/DerivedData/Foo-hkljicipwnivteazylcxtobonsbc/Build/Intermediates/Foo.build/AdHoc-iphoneos/FooTests.build/Objects-normal/arm64/FooTests normal arm64
Running the Ld command manually results in this...
ld: file not found: /Users/mluton/Library/Developer/Xcode/DerivedData/Foo-hkljicipwnivteazylcxtobonsbc/Build/Intermediates/Foo.build/AdHoc-iphoneos/FooTests.build/Objects-normal/armv7/FooTests
If I navigate to that directory I see the file is indeed not there. I do see bunch of AFNetworking related files along with FooTest* files. Most have extensions like .d, .dia, and .o. But there's no FooTests which is what the linker is looking for.
If I edit the 'Foo' scheme I see there are two targets in the Build item. Foo and FooTests. If I uncheck everything associated with FooTests then the command line build will work fine.
Has anyone else tried this and run into the same problem? Am I missing a build setting somewhere? Am I asking for trouble by trying to do unit tests for an Objective-C project in Swift?
I am building a static library. That library relies on a resource bundle that is another target in the same project. I am trying to create a Run Script, that will generate the resource bundle every time I am building the static library and puts it into same folder. With this script I managed to do that for iOS Simulator:
xcodebuild -target LibsResources -configuration ${CONFIGURATION} -sdk iphonesimulator BUILD_DIR="${BUILD_DIR}"
But for some reason this script also generates empty build folder ("build/MyLib.build") at the root of the project. Why and how I can disable it?
Bonus question: How I can specify the sdk(-sdk iphonesimulator or -sdk iphoneos) in the script so it changes depending if the library is built against iSO simulator or iOS Device?
I am trying to work with the ffmpeg library on a cygwin development environment. I downloaded the shared build from here (64-bit). The bin folders contain dlls but no .a or .dll.a files. Linking, which is done like so:
$ gcc encoding_mp3.o -L/cygdrive/c/Users/Desktop/webserver/cygnus/lib/w32api -L/cygdrive/c/Users/Desktop/webserver/cygnus/ffmpeg/ffmpeg_shared/bin -lavcodec-54 -lm -luser32 -lpthread -o encoding_mp3
results in the following error:
/cygdrive/c/Users/Desktop/webserver/cygnus/ffmpeg/ffmpeg_shared/bin/avcodec-54.dll: file not recognized: File format not recognized collect2: ld returned 1 exit status
My question(s):
1. The bin/ folder in the shared build contains only avcodec-54.dll. Is there a way to convert the dll to a dll.a or .a?
2. Where am I going wrong?
If source code is required, please let me know.
You need to download the "dev" versions, or the "static linking" ones (a little down, on the page).
dlls cannot be converted to libs, nor can they be used (usually) to generate they own little import stubs (the .dll.a)
From the page you linked "Dev packages provide the headers and .lib/.dll.a files required to use the .dll files in other programs."
.a / .lib usually are located in "lib" folders.
I'm triying to find leaks in my project chibi-ORM using the tool of scan-build as suggested in other threads.
But when run from the terminal:
/Users/mamcx/Downloads/checker-0.138/scan-build -k -V xcodebuild
I get this:
009-01-13 10:33:18.296 xcodebuild[14025:4213] Warning: Couldn't discover the 'ccc-analyzer' compiler's built-in search paths and preprocessor definitions for language dialect 'objective-c'. This may lead to indexing issues.
Compiler: /Users/mamcx/Downloads/checker-0.138/ccc-analyzer
Reason: gcc-4.0: installation problem, cannot exec '/Developer/usr/bin/arm-apple-darwin9-gcc-4.0.1': No such file or directory
However, I can build & debug just fine from the XCode Ide. This is a problem with this tool or something wrong on my side?
There's no need to change the project, just add the -sdk flag to the xcodebuild command, for example:
scan-build -k -V xcodebuild -configuration Debug -sdk iphonesimulator2.0
You can change the 2.0 to be 2.1, 2.2, 2.2.1, or 3.0 to match your target SDK.
the build is failing due to code signing reasons
the fix for iphone apps would be to just go to the project’s properties and set the “Base SDK” to “Simulator - iPhone OS 2.1″ rather than “Device”
check in your case what it would be
What I did to get this to work was to create a new build configuration (which was a dupe of my debug config), which I called Clang, then did the following in the project settings:
set "base SDK" to "Simulator - iPhone OS x.xx"
set Code signing Identity to - "Don't Code Sign"
then, when I run scan-build I do:
scan-build xcodebuild -configuration Clang
(obviously if you named your new build config something different use that name there).
Then it all worked fine and found no bugs in my code (except one false positive) :-)
Also, make sure you do a clean before each scan-build with:
xcodebuild -configuration Clang clean
Otherwise scan-build won't scan the files that have already been built.
Make sure that you can first run xcodebuild on the command-line for your project. In my case I discovered that my project was doing the release build by default and was trying to build for the device. Xcode must add some magic to make it work with certificates because I got the same error messages.
Once I explicitly told it to build with the Debug configuration all worked well. So you may have to run CLang/LLVM with scan-build xcodebuild -configuration Debug.