I have been trying to fix some errors appearing on a code I am currently using. I did all the actions at the ReadMe files,I followed all the instructions given at git, and I still get errors at almost every header (i.e. Lexical or Preprocessor Issue Group
config.hpp:19:10: 'boost/config.hpp' file not found)
After some tries, I think that my Xcode project doesn't read the libraries, as it should. I started fixing the problem manually, by setting the exact path of every header, but there is no point to do that, since I am going to use this project in a different computer too, where the repository won't be the same.
After that, I installed AFNetworking 3.0 and CocoaPods, since I read that it would help, but I didn't managed to solve the errors.
I am using
-OS X Yosemite version 10.10.5
-Xcode version 7.0
Related
everything worked without issues, now with MacOS Mojave i get this in Xcode:
#import <iTunesLibrary/ITLibrary.h>
Error: File not found
Already tried reading the Framework, ensured the search paths are set, but nothing changes...
The funny part is, Xcode knows about the framework, because it suggests it while typing the Command, but on compile, it fails, cannot create App Updates anymore due this reason.
Solved it myself, the new Xcode broke all the Framework Search Paths, had to remove all entries and fix other Frameworks by hand, but it works now
I've spent the past few months converting a project of mine with about 1500 source code files into Swift. It was incredibly tedious, but I finally did it. It runs well, builds well, but:
When I attempt to archive the project, Xcode fails with the following error:
ditto: can't get real path for source '/Users/USER/Library/Developer/Xcode/DerivedData/
APP-dtsbrzschafjiubelceuxtfwstqf/Build/Intermediates/ArchiveIntermediates/APPCore/
IntermediateBuildFilesPath/APPCore.build/Release/APPCore.build/Objects-normal/
x86_64/APPCore.swiftmodule''
Command /usr/bin/ditto failed with exit code 1
APP being the app and APPCore being the embedded framework.
What I've tried:
cleaning the project (which really has no effect when archiving, since archive always compiles from scratch)
using Xcode 7.2 beta (released a few days ago)
making as many declarations as possible non-public
disabling any Swift optimizations for the release build configuration
building the APPCore framework as release - which actually works (!) - and does (!) create the .swiftmodule file
The last part being the strangest here. This evidently points to the archive doing something slightly different, but I have no idea what.
My question is if anyone has any idea why is this happening and how to debug this. I've spent the last two days trying to figure this out, but no results...
I've googled this error as well, but unfortunately, the answers were fairly limited and suggesting to comment all lines of code and then start slowly uncommenting them until the project builds. Which is OK for a smaller project, but not for a 25KLOC project, mainly when you have absolutely no idea where to start...
I had the same issue and your question actually helped me to solve it (Xcode 8).
In debug mode just got the "ditto: can't get real path for source" without any further information. Switching to release mode showed me that the problem was that the framework wasn't allowed to have a bridging header file. I went to the build settings and removed the bridging header file (don't know why there was one) and it now compiles both in release and debug mode.
I am working on a fork of the Xbox HID project (to allow greater configuration of the controller) and came across a really strange issue.
The project is three projects, which I have grouped together under a workspace, which works well, it compiles them in order (kext, daemon and prefpane) and all works.
However, I decided to uncrustify the code (thanks Alcatraz!) and standardise the names and locations of source files. This required me to update the project as file paths changed.
Once this was all completed the PrefPane wouldn't load. For some reason it was instantiating and sending initWithBundle to an object that was NOT the File's Owner in the XIB.
After a lot of debugging and hair-pulling I discovered the object it was instantiating also happened to be the first file listed in the Compile Sources build phase. Once I moved the correct file to the top of that list the PrefPane once again launched and worked as expected.
That seems wrong, why does it need to compile this particular class first... better yet, why is it picking up only the first compiled class instead of the one specified in the XIB?
I am using Xcode Version 6.2 (6C131e) under OSX 10.9.5, however, I am using the OSX 10.6 SDK and have 10.6 as the deployment target.
I was having some other issues with the project in question, so I rebuilt all three projects and this issue went away.
I am guessing there was some sort of issue with the Xcode project itself as I believe it was probably upgraded from at least two previous major versions of Xcode.
Lesson here seems to be, rebuild the project files themselves and see if that fixes the issues!
I should mention that I originally posted this as an issue on Neovim's tracker, but it hasn't been getting a ton of traction there lately and I'm beginning to suspect that it's more an issue with my setup rather than Neovim itself.
Essentially, I had stopped building neovim nightlies for a few months. Having heard that it's getting integrated terminal support I decided to rebuild using the latest source, only to get a persistent, odd error. No matter what my build settings are, it always boils down to make hitting an error when it has to compile a file called loop.so. I hadn't noticed this issue with any other software I try to build, but I suspect it could be an issue with my environment.
Does anyone here know what this file's role is, and why the compilation could be failing at that point?
You might need to install the full Xcode app and not just the command line. This fixed the issue for me.
The issue turned out to be a bad typedef in a libuv header, object.h.
I'm very new to objective-c, xcode, and mac development in general (I
come from a java development background). I'm attempting to integrate
GHUnit into xcode to write some simple unit tests for an objective-c/
cocoa project I've recently been tasked with.
I've attempted to follow the directions here :
http://gabriel.github.com/gh-unit/_installing.html for:
Installing (Mac OS X)
-- Installing in /Library/Frameworks.
I'm working with xcode 3.1.3 running under Mac OS 10.5.8
I have created the new Target "Tests", and Link Binary With Libraries
shows the GHUnit.Framework.
I've added the GHUnitTestMain.m to the project as the directions
describe. However, I get "error: GHUnit/GHTestApp.h: No such file or
directory" for the #import
I looked for this header file in the framework and I don't see it
included. #import is not causing any errors, and I
DO see this file in the framework directories.
Is the downloaded framework and the GHUnitTestMain.m out-of-synch with
each other? or have I missed something in the configuration?
As another note, in the directions:
"If your main target is an application, you will need to include these
source files in the Test project manually."
I don't understand what action is required from this statement. I
have no idea if it's related to my current compilation error.
Thanks for any help in sorting this out.
Make sure you downloaded the OS X version of GHUnit. The github page lists a few downloads for iOS aswell. At the time GHUnit-0.4.26.zip is the latest OS X version.
I encountered the same problem.
You might add the test class to the main application target. Uncheck the target and then, the error "GHUnit/GHUnit.h file not found" disappeared.