I'm using Vapor, and I've run into a problem where the change to Xcode 13.3 from 13.1 now means the project (without changes) will no longer build.
How can I change the version of Swift that a Vapor project will build to? Since this isn't an app, the usual convenient configuration UI isn't available, so I presume this has to be done in a configuration file, or via the terminal. Just don't know how, is all...
I think what you mean is the version of swift-tools that gets invoked rather than swift. Change the first line of Package.swift in your project's folder to use the current version needed by the latest vapor version 4:
// swift-tools-version:5.5
Then use Xcode to try to build. If this doesn't work, try Using the Clean Build Folder menu option off the Product menu and try again.
Failing this, use terminal to remove the .build folder in your project's folder and do a swift package update followed by a swift build. I know of at least one swift compiler bug that means a compile that fails with swift build will succeed with swift build -c release so it could be worth trying both.
If all this fails, include more detail in your question to show the exact cause of 'will no longer build'.
I am trying to get Xcode 10.2 to convert my hybrid Objective-C / Swift project to use Swift 5. Whenever I do this, however, the compilation files due to the following error
error: Multiple commands produce '/Users/<User>/Library/Developer/Xcode/DerivedData/SurgEval-chcbdqcuvbtwckedraqzdhwbsqpm/Build/Intermediates.noindex/SwiftMigration/SurgEval/Products/Debug-iphonesimulator/MYAPP.swiftmodule/x86_64.swiftmodule':
1) Target 'MYAPPTests' (project 'SurgEval'): Ditto /Users/alenox/Library/Developer/Xcode/DerivedData/SurgEval-chcbdqcuvbtwckedraqzdhwbsqpm/Build/Intermediates.noindex/SwiftMigration/SurgEval/Products/Debug-iphonesimulator/MYAPP.swiftmodule/x86_64.swiftmodule /Users/<User>/Library/Developer/Xcode/DerivedData/SurgEval-chcbdqcuvbtwckedraqzdhwbsqpm/Build/Intermediates.noindex/SwiftMigration/SurgEval/Intermediates.noindex/SurgEval.build/Debug-iphonesimulator/MYAPPTests.build/Objects-normal/x86_64/MYAPP.swiftmodule
2) Target 'SurgEval' (project 'SurgEval'): Ditto /Users/<User>/Library/Developer/Xcode/DerivedData/SurgEval-chcbdqcuvbtwckedraqzdhwbsqpm/Build/Intermediates.noindex/SwiftMigration/SurgEval/Products/Debug-iphonesimulator/MYAPPL.swiftmodule/x86_64.swiftmodule /Users/<User>/Library/Developer/Xcode/DerivedData/SurgEval-chcbdqcuvbtwckedraqzdhwbsqpm/Build/Intermediates.noindex/SwiftMigration/SurgEval/Intermediates.noindex/SurgEval.build/Debug-iphonesimulator/SurgEval.build/Objects-normal/x86_64/MYAPP.swiftmodule
I have already tried switching to using the 'Legacy Build System' as suggested in other similar questions, but I would like to migrate to the new build system.
I have also tried to change the product module name in my test target as suggested in another question, but that broke my tests.
The application and tests both build and run fine otherwise, I just get a compilation error while running the Swift 5 migration tool.
Any idea what's going on here, or some some docs I can look at to better understand this?
Thanks!
I was able to partly solve this issue by adjusting SWIFT_MODULE_NAME property in Test target.
My test's target SWIFT_MODULE_NAME was same as main target name, so i changed it
I just recently downloaded Xcode 6 beta 4, and my swift project compiles with no errors but before it gets to my code I get a dyld_fatal_error just above start in the call stack.
and a breakpoint in some assembly code with a nop instruction
The console error I get is
dyld: lazy symbol binding failed: Symbol not found: __TFSsa6C_ARGVGVSs13UnsafePointerGS_VSs4Int8__
Referenced from: /Users/username/Library/Developer/Xcode/DerivedData/Sudoku-dhrdonaeqzsgcvewndimxbbsltnc/Build/Products/Debug/Sudoku.app/Contents/MacOS/Sudoku
Expected in: /Users/username/Library/Developer/Xcode/DerivedData/Sudoku-dhrdonaeqzsgcvewndimxbbsltnc/Build/Products/Debug/Sudoku.app/Contents/MacOS/../Frameworks/libswift_stdlib_core.dylib
dyld: Symbol not found: __TFSsa6C_ARGVGVSs13UnsafePointerGS_VSs4Int8__
Referenced from: /Users/username/Library/Developer/Xcode/DerivedData/Sudoku-dhrdonaeqzsgcvewndimxbbsltnc/Build/Products/Debug/Sudoku.app/Contents/MacOS/Sudoku
Expected in: /Users/username/Library/Developer/Xcode/DerivedData/Sudoku-dhrdonaeqzsgcvewndimxbbsltnc/Build/Products/Debug/Sudoku.app/Contents/MacOS/../Frameworks/libswift_stdlib_core.dylib
Just so you know the project still compiles, and runs fine with Xcode 6 beta 3.
Most extremely weird problems like this can be solved with a Clean & Build (or perhaps relaunch Xcode). You might also consider deleting the relevant folders from ~/Library/Developer/Xcode/DerivedData.
For sure this error is very unhelpful:
dyld`dyld_fatal_error:
-> 0x1200ad088 <+0>: brk #0x3
This of course occurs only on device, not the simulator. Another good reason to always test on a device.
Anyway, having had the same issue, a clean didn't work for me. Deleting DerivedData didn't help either. Also tried synchronising the Deployment Target versions. That didn't seem make any difference but I did it anyway.
Solution was to add any dynamic frameworks to Embedded Binaries setting under Target -> General:
Now I know that has been mentioned in other answers. However, if I can supplement by saying that any dependent dynamic frameworks must also be included.
So for example if you have a dynamic framework A that depends upon dynamic framework B, then it's necessary to have A and B added to Embedded Binaries.
Note that if the dynamic framework A depends upon any static library or framework, you will almost certainly be forced to create A as an umbrella framework that includes the dependant binaries.
Other considerations that may or may not be important. However did personally for me result in success were;
paths of each dynamic library in the Inspector were set to "Relative
to Group". In the screen grab above the path of the embedded binary
appears correct terminating with "build/Debug-iphoneos".
dynamic frameworks are in embedded binaries section. Static libs and
static libs wrapped up as frameworks are in Linked Frameworks
and Libraries. Nothing appears in both sections.
In setting this up XCode behaved strangely. The following proved successful:
Add the dynamic framework to the embedded binaries.
Find the new framework in XCode groups on the left and update the path to be
"Relative to Group" as described previously.
Delete the dynamic framework from embedded binaries.
Add the dynamic framework to the embedded binaries again. The path should now appear correctly.
Delete all references to the dynamic framework from the Linked Frameworks
and Libraries section.
I have just had this problem trying to link a custom iOS framework to my project, so for anyone out there who has this problem, it's to do with the copy files build phase.
I think that this error results when a file cannot be found. So create a copy files build phase in the appropriate target in your project. Then add the file (in my case the custom framework) to this phase (if it's a framework make sure to select the 'Frameworks' destination).
Cleaning, restarting, deleting etc didn't work for me.
I have a project containing another project. When I ran the project on iOS 7 and the contained project was accessed in code, the app stopped at the line below:
After many days, I saw that the deployment target for the container project was 7.0 (as can be seen below).
The contained project on the other hand, had a deployment target of 8.1 (as can be seen below).
Changing the deployment target of the contained project to 7.0 solved my problem!
The project was working fine on iOS 8 devices.
I had this issue recently and the problem for me was that I had added a library from the same project which wasn't listed in 'Embedded Binaries' from the 'General' section.
NOTE: If you add it in Embedded Binaries it will also add to the Linked Libraries section, possibly adding the same one twice.
Clean and build won't work. You'll need to delete he cache in ~/Library/Caches/com.apple.dt.Xcode* directories. Delete these and rebuild.
Do this every time you upgrade the beta.
I also faced the same issue and tried all the solution given above without any luck.
then what I have done to resolve that I really don’t have much I idea about. So there is Certificated called “apple worldwide developer relations certificate authority” in System group in keychain Access and due to some profile and certificate issue I randomly mark this certificate “Always trusted” from “Use System Defaults”. So this is causing this “dyld_fatal_error” crash to me. when I revert it back to “Use System Defaults” crash got resolved.
So guys if you are tried all the possible option to resolve this crash and didn’t succeed yet, try this also. It helped me, may help you as well.
Found this about this certificate.
This problem still occurs in Xcode 7, and it can happen for a variety of reasons (it seems). In my case, the iOS app with an included framework:
ran on the simulator fine
gave the error you described on the device
The answer was to NOT use linked libraries but rather Embedded Binaries under General.
Also see here: https://stackoverflow.com/a/34052368/8047
Adding the non-system Framework to "Embedded Binaries" inside the general tab of the main project worked for me.
As stated by bitwit, this will also add your framework to "Linked Frameworks and Libraries", so watch out for those duplicates.
Tested with Xcode 7.3.
Xcode 8.
Clean and build didn't work. I deleted the cache, deleted Derived data. After that, my pods configuration was broken, so i needed to install pods again. Pods Target configuration was set to a very old Valid architectures. setting to armv7 and armv7s, was ok to compile and no problems
You'll get this if your scheme has "Guard Edges" enabled in diagnostics when running on an actual device. "Guard Edges" only works in the simulator.
I was using cocoapods and had this problem as well when I updated to deploy target iOS 8 and added use_frameworks! to my Podfile. I was able to fix it by adding the following line to my Podfile:
link_with 'TargetName1', 'TargetName2', etc.
Might work with ProjectName as well
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'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.