I am trying to compile a Cocoa app in xcode 4.0 and I'm getting this error...
fatal error: 'string' file not found
...when trying to compile to .pch file on this line:
#include <string>
I have another xcode project that does the same thing, but does not get the error. I have scoured the build settings for some different, but I can't find one. The only difference is that the project that compiles OK was started as a command line project, not a Cocoa project, but the build setting are the same.
The target OS is Mac OS X 10.6
The error happens when compiling the precompiled header and doesn't get to any of the other files. The only framework that the compiling version has is Foundation.framework and the non-compiling one has it as well.
Why is it not finding in one project and not the other? Any advice?
What is the extension of your source files? If it is ".m", try to change it to obj-cpp ".mm", so that Xcode will deduce correct language.
Or just put c++-specific headers inside "#ifdef __cplusplus" block
Update
The guard must exist for each language compiled in the project because this specific include is in the pch. IOW, if it were all c++ and/or objc++ there would be no error. Evidently, there is at least one file that does not recognize C++ (e.g. C or ObjC sources are also compiled in the target). Therefore, you simply guard it like so:
// MONPrefix.pch
#ifdef __cplusplus
#include <string>
#endif
// same for objc, so your C and C++ sources compile with no error:
#ifdef __OBJC__
#include <Foundation/Foundation.h>
#endif
string is a C++ header (for std::string). If you are looking for stuff like strcpy you need to include string.h
Related
Hi I have a problem with getting ffmpeg libraries to build in my Xcode project. It is in C++ . I have installed it using homebrew and have checked that all the correct libraries have installed via terminal. I have tried with and without extern C as I know it is a c library.
#include <iostream>
#include <opencv2/opencv.hpp>
#include <libavformat>
//extern "C" {
// #include <libavformat>
//}
The linker flags have been set by using (e.g. pkg-config --libs libavcodec) in terminal and these flags do not throw up an error when building. The header files are also found with no problems as the autocomplete flags them top while typing.
Please see attached pictures for Xcode build settings. Really stuck pease help
I identified the problem as being related to the path that the include statement relates to. The header files were one down in the hierarchy from the folders so:
#include <libavformat>
produces an error that the library was not found. The change below sorted the problem out.
#include <libavformat/avformat.h>
I have an OpenGL file called wglew.h which I downloaded from http://glew.sourceforge.net/. Using the wglew.h as I downloaded it, I receive the following error when compiling a program that I have (I am using MacOSX):
/Users/Downloads/glew-1.11.0/include/GL/wglew.h:70:10: fatal error:'windows.h' file not found
I am trying to go back into the source code of that file and change its dependency from windows.h to something that my Mac could recognize. The source code snippet in the wglew.h file is:
#if !defined(WINAPI)
# ifndef WIN32_LEAN_AND_MEAN
# define WIN32_LEAN_AND_MEAN 1
# endif
#include <windows.h>
# undef WIN32_LEAN_AND_MEAN
#endif
Is it possible to work around this windows.h dependency so that my program does not error out at this step? I asked a similar, but not identical question about a parallel concept at: Where can I get windows.h for Mac? Perhaps instead of looking for an equivalent windows.h file (if such exists for the Mac), I can try to devise a more subtle approach of changing the source code within the wglew.h file to get my program to work and accommodate the windows dependency that I am experiencing?
Here we go again: GLEW is not part of OpenGL. It's a third party library.
You don't need GLEW on MacOS X !
You're barking up the wrong tree!
Instead of trying to fix GLEW (which you don't have to). Just fix your program to not use GLEW when being compiled for MacOS X.
Everywhere in your program where you find a
#include <glew.h>
or
#include <GL/glew.h>
Change it into
#ifndef __APPLE__
#include <GL/glew.h>
#else
#include <OpenGL/gl.h>
#endif/*__APPLE__*/
Put any occurance where a GLEW function is called between a
#ifndef __APPLE__
…
#endif/*__APPLE__*/
block as well.
You don't need GLEW on MacOS X ! Don't use it there.
I'm using the latest version of codelite with the built in mingw 4.8.1 compiler/linker.
The first issue I have, when I create a new g++ project in Codelite with MinGW and then add the -mwindows flag to the linker build settings to utilize (HBRUSH)GetStockObject(BLACK_BRUSH), any cout statement I have in code doesn't print to the console. I need the -mwindows flag for GetStockObject to work, but I have no idea why it would break the cout statement. The code compiles and runs just fine, just nothing gets printed to the console.
The second issue I have is when I try to instantiate a basic class that is in a different project but still under the same workspace. The linker will give out an undefined reference error when I try to instantiate any class in the other project if I just link the .h class file in the project I'm working in. For example:
Framework *test = new Framework();
will give out
E:/CodeLite/ElysiumEngine/Main/main.cpp:9: undefined reference to `Framework::Framework()'
When I include this api.hpp file in the header:
#ifndef FRAMEWORKAPI_HPP
#define FRAMEWORKAPI_HPP
#include "Framework.hpp"
#endif // FRAMEWORKAPI_HPP
but the code links and runs just fine once I do this:
#ifndef FRAMEWORKAPI_HPP
#define FRAMEWORKAPI_HPP
#include "Framework.hpp"
#include "Framework.cpp"
#endif // FRAMEWORKAPI_HPP
I've never had to link the .cpp file in any other compiler or project I'm working on. It doesn't make any sense to me.
Is there anything I can do to solve these two issues?
Just an answer to your 1st question:
The -mwindows flag causes the compiler to pass --subsystem,windows flag to the linker.
The linker flag --subsystem,windows causes your final executable to marked as a non-console (windowed) application and it also sets the default entry point to WinMainCRTStartup.
WinMainCRTStartup does not initialize console I/O and therefore anything printed/read at the console is ignored
OS X 10.6.8, XCode 3.2.6, Base SDK 10.5, Intel Compiler 11.1
I am getting a weird message when I try to compile that says:
catastrophic error: could not open source file "stdarg.h"
I am using a PCH, I did find: Xcode Intel compiler icc cannot find #include <algorithm>
which is a similar issue and I think that the source file type is set to .c.c instead of .c
From what I can see stdarg.h is:
/* This file is public domain. */
/* GCC uses its own copy of this header */
#if defined(__GNUC__)
#include_next <stdarg.h>
#elif defined(__MWERKS__)
#include "mw_stdarg.h"
#else
#error "This header only supports __MWERKS__."
#endif
so must be GNUC is defined, obviously.
Can anyone help me figure out how to better compile since this works without changes in GCC 4.0? Is there a global way one might have XCode re-evaluate the source file type to not be .c.c or .cpp.cpp I am not even sure how this would happen.
Also, is there a #define that I can check to see if the Intel compilers are being used to make special cases if I need to?
I looked at a few of the files referenced in the build results and looking at the source file type in XCode it says source.c.c and I think if I change that to source.c that compiler error goes away.
Hi I'm trying to compile a gcc based code on Xcode with the icc compiler (11.1.088)
but i have the following error:
catastrophic error: could not open source file "algorithm"
After looking to this file, it is located in the gcc include directory, but i get hundreds of errors...
Does anyone have suggestions ?
Thanks.
I was having a really stubborn error very similar to this question but with a different solution.
Algorithm: No such file or directory
My solution:
#ifdef __cplusplus
#include <algorithm>
#endif
I had the #include in a prefix header file (such as the .pch file Xcode gives you in a new project) which was causing it to be included in an Objective-C file, and apparently algorithm is C++ only. Either make sure all your Objective-C files are Objective-C++ (.mm) or add that directive to make sure it doesn't get included in those files.
What do you have set as your base SDK ? And what version of Xcode ?
FWIW I just tried a test with Xcode 3.2.3 and ICC 11.1 (under OS X 10.6 of course) - created a new C++ console application using the standard Xcode template, added #include <algorithm> to main.cc, switched from the default gcc 4.2 to ICC, and it compiles and runs without warnings or errors. The base SDK is the system default (10.6).
It may just be that you have a bad installation of Xcode and/or ICC, or perhaps you have changed a project setting such as base SDK, and this is causing problems.
This problem occurred on my machine, while developing an iOS app.
Xcode Version 4.6.3 (4H1503) & iOS version 6.0
I'm using AppCode for development and the IDE added (by accident) the following import statement:
#import <c++/4.2.1/ext/algorithm>
I met this error too, I just forget to change the source from .m to .mm. so, if adjust C++ complier cannot work, try to change the source file.