I am getting the following error only on Xcode 13.4.1 when I am trying to build the project.
Cycle in dependencies between targets '#aTargetName' and '#anotherTargetName'; building could produce unreliable results. This usually can be resolved by moving the target's Headers build phase before Compile Sources.
It gets solved if I "clean build folder" every time I need to run the project.
This is how the build phases are in the project:
***Update on 1/07/22:
The following line fix this:
Open Terminal and run:
defaults write com.apple.dt.XCBuild EnableSwiftBuildSystemIntegration 1
I had the same error. All the other SO questions refer to changing the order of the 'Headers' in the build phases or updating the build system to legacy.
I don't have a Headers phase so I just played around with what phases I did have. This is a daunting suggestion for anyone with more a few phases because permutations grow exponentially.
For myself here is the before (not working) and after (working) configuration.
Not Working
Working
I have no idea why one is working and the other isn't just that this change resolved my issue. I also commented out some localizing and linting scripts that aren't essential to run on release just dev/test builds. I also only got the error when arching the project - not when buildling.
Related
When running my UITests Target in Xcode10, I now get:
Library not loaded: #rpath/libswiftMetalKit.dylib . <--- (Library varies)
Referenced from: ../MyApp.app/PlugIns/MyAppUITests.xctest/Frameworks/Hero.framework/Hero <-- (Framework varies, all installed with Cocoapods 1.6.0beta1)
Reason: image not found)
My regular target works fine. My Regular target and UITests targets both have "Always Embed Swift Standard Libraries" set to Yes, though I noticed the Pods Project and frameworks have this set to No.
Things I've tried:
Cleaning project, deleting derived data, and rebuilding project
Verifying my code signing is working
Setting "Always Embed Swift Standard Libraries" to Yes on the Pods Project and frameworks.
adding #rpath to the Runpath Search paths for the UI Tests Target
So far nothing has worked. Anyone else encountering this issue or have insight into what might help?
EDIT:
Thanks #matt for pointing me in the direction of the related isue.
I tried importing UIKit and recreating target, both to no avail.
Importing the specific frameworks (i.e. Hero) or the libraries (i.e. MetalKit) in one of my UITest targets allows it to build, but mysteriously my other UITest target will still not build due to libswiftSwiftOnoneSupport (referenced by Alamofire) not building.
Still not sure if this is due to my Cocoapods setup (All my targets including UITest targets import all pods, which I think should be unnecessary but I get missing frameworks for my pods if I don't), but the exact same setup worked fine prior to XCode 10.
What worked for me was the followings:
Copy from your TARGETS from your basic project let say 'sample_app' > Build Phases the section [CP] Embed Pods Frameworks.
Now In the UITest TARGETS, let say 'sample_app_UITests' create a new Run Script and copy everything.
Clean/Build
Setting the workspace setting to Legacy build fixed it for me: File > Workspace Settings > Build System: Legacy Build System
Building on devices and simulator works fine in Xcode 10 but an archive build in Xcode 10 hangs up at the same spot each time (cpu maxes out too), at the very end of "Compile Sources" but never goes to the next build phase. Of course, when I quit the build I get an uncategorized SwiftCodeGeneration warning (also using legacy build system also fails, also same happens before and after updating to swift 4.2). Anyone else running into this?
Another note, not using cocoapods, tried removing all my embedded frameworks and still had the same issue.
remove the armv7 from supported architecture works for me
I found some answers to this problem.
I adjusted the level of optimization, this allowed me to get past the "compile sources" build phase (in particular "fastest and smallest" and "optimize for speed").
the compiling then got stuck on the "copy bundle resources" phase. making sure my project folder names matched the actual folder names and making sure all my resources were linked properly by deleting the reference to a few and re-entering them into the project I was able to successfully compile. Again this was a project that worked a couple days ago on Xcode 9. Hope this helps someone, cheers.
I'm trying to produce gcd a files from an iOS Xcode 4.2 (4D199) project called CocoaTouchHax on Lion and I'm having incredible trouble. I followed the steps here and I went as far as trying to build llvm/clang from source following steps here. However I continue to get this error:
Library not loaded: #executable_path/../lib/libprofile_rt.dylib
Where am I going wrong? I've tried to use the install_name_tool to fix the executable path to no avail. Am I over analyzing something? Am I missing something simple? I put this in as a "Run Script" phase prior to linking to ensure I've updated the #executable path and I use tool to examine the file after and the name is updated:
install_name_tool -id #executable_path/Users/cliff/dev/CocoaTouchHax/build/CocoaTouchHax/Build/Products/Debug-iphonesimulator/lib/libprofile_rt.dylib build/CocoaTouchHax/Build/Products/Debug-iphonesimulator/lib/libprofile_rt.dylib
What am I doing wrong? Help!
Update
Merely adding lib profile_rt.dylib crashes my test run immediately giving the following error when anything is run:
#executable_path/../lib/libprofile_rt.dylib
So I am certain that something needs to happen or something needs to be done to the lib profile_rt.dylib prior to execution.
Another Update I tried creating a sum link to
/Developer/usr/lib
under /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.0.sdk/Developer/usr
Which I believe is part of the base the path forming the current working directory when test runs. (Assuming it runs from the bin folder there.) This would, in theory, complete the relative lookup path of ../lib/libprofile_rt.dylib from that base path but it didn't work. I've tried running the install_name_tool command prior to copying the dylib in place but I still get this error:
Library not loaded: #executable_path/../lib/libprofile_rt.dylib
I don't know what I'm doing wrong. I somehow did manage to get test coverage files to emit using some combination of the above but I was not paying close enough attention and cannot reproduce the occurance. I know this can work, I just need a little more help figuring out how.
Update: In Xcode 4.3.2 (4E2002), just switch on Generate Test Coverage Files and Instrument Program Flow, the build system will link libprofile_rt for you. Xcode 4.3, and later, is a standard Mac app and the /Developer folder is gone. So, skip steps 5-7 below. You will also have to create a class file to workaround a bug in Apple's unix implementation as described here. You'll want it in the project under test.
For Xcode 4.2 (4C199) in Snow Leopard:
Create a project, say MyProduct. Check Include Unit Tests.
Once Xcode does its thing and loads the new project, you should have two targets, MyProduct and MyProductTests. Duplicate the MyProduct target.
Select the MyProduct copy target.
Go to Build Settings. Under Code Generation turn on Generate Test Coverage Files and Instrument Program Flow.
Go to Build Phases. Expand Link Binary With Libraries. Click the +. Click Add Other.... Browse to /Developer/usr/lib. Choose libprofile_rt.dylib.
Select the MyProductTests target.
Repeat steps 4 and 5 for that target.
Go to Build Settings again. Find Bundle Loader under Linking. Change the path to the MyProduct copy app. Something like $(BUILT_PRODUCTS_DIR)/MyProduct copy.app/MyProduct copy.
Change your schemes so that the tests run under the MyProduct copy scheme and not MyProduct. If you're compiling clang on your own, you can figure out the details here.
That should work. Step 8 took me hours to figure out, it's the key. If you only see gcda files in the test build directory, that's the likely issue.
On Lion you can symlink the dylib into /usr/lib to avoid that error
sudo ln -s /Developer/usr/lib/libprofile_rt.dylib /usr/lib/libprofile_rt.dylib
I cant guarantee that that wont bust something the future however. Remember that you have done it.
Create a new configuration called "Coverage" (or whatever).
In the Coverage config variant you have created go to Build Settings and...
Add -fprofile-arcs and -ftest-coverage to Other C Flags
Switch on Generate Test Coverage Files
Switch on Instrument Program Flow
In Other Linker flags add -lprofile_rt
The reason to do it this way with a config is that you can keep your normal build untouched. Also only works on Simulator. So dont try running this on device.
And from http://mattrajca.com/post/8749868513/llvm-code-coverage-and-xcode-4
Finally, open up the Intermediates/$TARGET.build/$CONFIG/$TARGET.build/Objects-normal/$ARCH subfolder. Inside, you’ll find the aforementioned gcda and gcov files
You can open that folder with CoverStory.
Note that coverage is not cumulative (unlike Coverity) so each run starts afresh. There might be a way to change that.
I try to automate my UI testing (using FoneMonkey ).
I have several targets, linked to different frameworks.
The issue is that I have to clean my targets before building them. If not, it looks like it loads unwanted frameworks (and thus has unexpected behavior).
So I'd like to know if there is a way to auto-clean the target(s) before building, by setting an option, using a run script...
I tried using
xcodebuild clean
But I get an
ASSERTION FAILURE in /SourceCache/DevToolsBase/DevToolsBase-1763/pbxcore/Target.subproj/PBXTarget.m:597
Any idea ?
Thanks
You can force the top level project to rebuild from scratch by removing the build directory. e.g. rm -rf build. This may be sufficient for your needs.
Otherwise, upgrade to the latest version of XCode, and failing that, submit a bug report.
I'm looking to build + run my iphone xcode project totally outside of xcode.
Currently I'm using xcodebuild to build the project - which seems to build cleanly:
https://gist.github.com/8eadfb1acca4d101624b
Unfortunately it doesn't seem to replicate the same Build as done by xcode. Rebuilding it leads to a bunch of syntax errors.
Are there other flags I should be passing xcodebuild?
Maybe you have a problem with shared precompiled headers? Like, building different versions of a project on the same machine. Try stating "clean build" (or clean install, whatever you want to do) as build actions at the end of your xcodebuild call.