I check this answer with no success.
Maybe sounds obvious but I look for inside the path and effectively does not exist the path, but this path is used for Xcode and not for my code (at least not that I know it)
The folder suppose to be here the but it does not exist (create the folder manually but does not fix it)
Somebody have an idea ?
I had the same problem, here's how I solved it:
Go to the "Build Settings" of the Tests Targets (Make sure it's the "Tests" files with the white building block logo) and erase the Framework Search Paths.
Since you claim that the path doesn't exist, I suppose you were looking under the normal file instead of the "Tests". At least that was my mistake.
Good Luck!
I changed the last "Developer" in the Tests target's "Frameworks Search paths" path to "System" (...iPhoneOS9.0.sdk/System/Library/Frameworks) because there is a System/Library/Frameworks directory. My code builds and the warning goes away.
Ups !!
I have the problem in the Test Compiling.
I delete the path and fix it.
I have the same problem. I can temporarily rectify the issue by selecting "Product - Clean" from the menu. It soon returns though.
Related
while building xamarin forms android app in debug mode
I am getting following error
Unable to remove directory "obj\Debug\90\android\bin\classes". Could not find a part of the path 'AccessibilityManagerCompat_AccessibilityStateChangeListenerImplementor.class'.
unable to find resolution for this as line number is not shown
Your path to the solution could be too long. I solved this by moving my solution closer to the C drive root. Also take into account that your application might not have sufficient rights to access that location, so make sure you give the necessary access rights.
Manually delete your bin/obj folders from your Solution, and then try to rebuild.
Usually this does the trick, since it is trying to remove a class that he cannot find a path of.
Manually deleting the obj\Debug\90 folder and subsequent build worked for me.
Clean and Rebuild didn't do it for me.
You need to make sure that the path is short and you dont have any spaces or special characters in the path to your project
The latter one was the issue that haunted me for a while.
For example: C:/abc xyz/ProjectName/... is unacceptable because there is a space between abc and xyz.
I don't exactly know why but this works for me
Happy coding!
This is the warning that it is showing:
directory not found for option '-F/Applications/Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS9.0.sdk/Developer/Library/Frameworks' "
Can anyone help resolve the warning?
This is how I fixed this problem
Further to a migration of my Xcode project, from Xcode 6.4 to Xcode 7, I get the warning message below (after compilation) for the Test target :
directory not found for option '-F/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator9.0.sdk/Developer/Library/Frameworks'
Actually I found something when comparing a new project vs an older one...
In the old project, the warning was only being produced by the test target of my projects. Under 'Search Paths', I found it was including two items under 'Framework Search Paths':
$(SDKROOT)/Developer/Library/Frameworks
$(inherited)
The new project kept the 'Framework Search Paths' empty.
Deleting those entries in my older project then removed the warning.
Notes:
I have not exhaustively compared settings, so there may be additional differences.
Also, just in case if one day you re-encounter one of the two following warning messages, just remember that you will have to do that: if the warning is for option '-L/...' that is Library Search Paths, delete the stuff there. However if the warning is for option '-F/...' that is Framework Search Paths, delete the stuff there.
Based on the error message, it sounds like the first order of business is to get the target's path straightened out. You can edit the paths as shown in the answers to this StackOverflow question. Be sure to check the path for all your targets if you're not sure which is generating the error --- this threw me for a bit after upgrading a project to the Xcode 7 beta; there was a path in the FRAMEWORK_SEARCH_PATHS for the test target that needed to be deleted. The path that was in there was exactly the path you report getting the warning on; removing the path eliminated it.
King-Wizard is essentially correct, to elaborate a little more -
Xcode 7 is looking for your testing framework XCtest.framework in a path that does not exist. The path set by $(SDKROOT)/Developer/Library/Frameworks under 'Search Paths -> Framework Search Paths' is looking for the framework in /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS9.0.sdk/Developer/Library/Frameworks which is not a valid path. You can delete the line $(SDKROOT)/Developer/Library/Frameworks to remove the error and still be able to run tests.
The correct path to 'XCTest.framework' is /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/Frameworks for those that are curious.
I hope that helps.
I had the same error with Xcode 9.2 and here is my solutions without doing by hand:
Click on your project in Project Navigator
Go to targets and click on MyProjectNameTest
Click on Build Settings and Search for “Framework Search Paths”
Under Framework Search Paths, delete the paths and keep the “$(inherited)”.
For those of you that have the following error:
directory not found for option ‘-L/…
that means it’s a Library Error, so you can try follow the below steps:
Click on your project (targets)
Click on Build Settings, Search for “Library Search Paths”
Under Library Search Paths, delete the paths and keep the “$(inherited)”
I am trying to compile a c++ simulation, that was previously written in VS2008.
It gives error exe not created, because "Always Create" was specified.
I have tried every solution, edited devenv.xml, changed verbosity output. Kindly anyone could give any idea.
Thanks.
This problem will occur when one of the include files listed in the project doesn't actually exist. You may have deleted the file, but forgot to remove it from the project.
The dependency checker then believes the project is not up to date, but the builder finds nothing to build.
A quick check that all project files can open in editor will help you fix this problem.
Well, it could be because a dependency, or the verbosity output level. Here are more options to you to take into account:
https://social.msdn.microsoft.com/Forums/vstudio/en-US/38c08137-3bb0-4143-b97f-72d077646318/visual-c-2010-build-questionissue?forum=vcgeneral
IBCocoaSimulator crashes when IB cannot find the framework, I assume that happens to you too. I can run IBCocoaSimulator without crash, when I manually copy my framework+ibplugin from the build dir into /Users/username/Library/Frameworks. I'm doing this with Finder, this is not optimal, but works.
I have searched for a smarter way and each solution (BWToolkit, BGHUDAppKit, KTUIKit) I have been looking at, does things in much different ways. One solution runs a sudo script that copies it to the system wide /Library/Frameworks. Another sets #loader_path and yet another uses #executable_path. I haven't had luck with any of them and because of the great differences it's hard to see the pattern.
I'm confused.
How do you config you IBPlugin, so that you can embed it in your app?
UPDATE 1:
Yay, solved it, after reading a blog post by dribin about how to use #rpath, I figured out how to get it working with my IBPlugins. So copy using Finder is no longer needed.
What I did was:
For MySmallFramework set Installation Directory to #rpath
For MySmallPlugin set Runpath Search Paths to #loader_path/../Frameworks
For MySmallApp set Runpath Search Paths to #loader_path/../Frameworks
Nice.
Might be obvious to most of you, but neoneye's solution as posted in his "Update 1" requires your plugin target to have a "copy framework files" build phase with the given framework assigned to.
(don't yet have enough points for direct commenting :( hence the answer post)
You can call this with external makefiles xcode project from ibplugin makefile like following example:
install_name_tool -change #loader_path/MyPluginName.framework/MyPluginName #loader_path/<absolute path or level to updirectory>/MyPluginName.framework/MyPluginName $(BINDIR)/MyPluginName.ibplugin/Contents/MacOS/MyPluginName
I am trying to set up Xcode for a project which contains multiple executables and static libraries. I have created multiple targets and set up the linking and dependencies, and initially everything works great. The catch...
This is an existing project which already has Visual Studio and Makefile builds. Those builds put the libraries in a lib/Debug directory and the executables in bin/Debug. So in Xcode I changed the Build Products Path to "lib" and "bin" respectively (so we can use one set of documentation for all of the platforms). This puts the compiled targets in the right place, but completely breaks both the linking (Library not found) and the dependencies.
I can fix the linking by adding $(SRCROOT)/lib/Debug to the Library Search Paths for each executable (but it feels like Xcode should be able to figure this out on its own, which makes me think I'm doing something wrong).
But — I can't figure out how to get the dependencies working again. If I change a library source file, the library will rebuild but not the dependent executables. If I force a build of the executable Xcode returns success without doing anything; it thinks the target is up to date. If I clean the target and then rebuild it works.
So, any ideas here? Is Xcode being fundamentally stupid in this regard, or is it me (I'm leaning toward the latter)?
Update: I've posted a sample project to demonstrate the issue at http://share.industriousone.com/XcodeDepsIssue.zip. Build it once, then modify MyStaticLib.c and build it again. The executable will not relink (and it should). Many thanks for any help on this one.
starkos, thanks for publishing your conclusion. It validated my experience as well. This situation really screwed me, so it was nice to know I wasn't just missing something.
I did however discover a workaround that avoids creating multiple projects or keeping the library and its dependent in the same directory. It is a hack, but it does work here.
I know it's a bit late but better than never.
For the dependency library, add a "Copy Files Build Phase", with Absolute Path as the destination, and the path text field should be the directory where the DEPENDENT target lives. Then click on Products, find the dependency library (will end with .a), and drag it into the "Copy Files Build Phase." If you now build, this will put the library into its own directory like before and THEN also copy it into the dependent's target directory.
For the dependent, you can now remove the dependency's output directory from the Library Search Paths. This will cause it to find the library copy. If you do this, the dependent will indeed be relinked each time the dependency .a is relinked.
The negatives are, of course, the extra time for the copy, and the necessity to specify (in the Copy phase) the target directory for each dependent of your library. Beats the hell out of the alternatives though....
Xcode doesn't automatically set up dependencies based on use of build products; you have to set up explicit target dependencies yourself.
Project > Edit Target Settings, General tab, + button, add any targets that are prerequisites to building the selected target. That should get you going again.
I've researched this some more and the answer is no, Xcode 3.x doesn't track dependencies between targets that live in different directories. You can work around it by giving each library its own project, and adding each of those to a master project. Or you can keep all of your targets in one directory. Pick your poison.
Here is my solution for this weird behavior in xcode 4.3.1. You have to add build pre-action in scheme:
rm -f ${BUILT_PRODUCTS_DIR}/${EXECUTABLE_PATH}
and choose which build settings to use for this script. Each time before build, target executable will be removed and rebuild completely. It helped for me, and i hope it helps you.
NOTE: Have tried to put this script in project build phase, and result was negative - debugger could not connect process to start debugging.
Good luck!
OK, it would help to have the text of the Linking... build line that's failing. But a couple of things:
1) You shouldn't be linking to anything in $(SRCROOT). That's your project sources. The two places to find things to link are $(SYMROOT) (the Build Products directory) or $(DSTROOT) (the Installed Products directory).
One thing you could do is to have a common Build Directory, then use 'xcodebuild install' action to install the products in the Installation Directory. The other is to use a Copy Files build phase to copy them after building, so you can link against them in $(SYMROOT) but still have them where your Windows compatriots expect them.
THere is probably a way to set up the per-target build products directories correctly, but I'd really have to see the project itself to figure it out.