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.
Related
I have a compilation error on macOS v11 (Big Sur) with the standard Clang compiler (version 13.0.0).
I am trying to include the sys/sysmacros.h to use the makedev() function which surprisingly is mentioned on the Apple developer website and should be compatible with macOS 15.5+.
Including sys/types.h also gives me an error, however sys/stat.h works. Sadly it still doesn't give me the makedev(), major() and minor() functions that I need.
The Linux manual page of makedev states there were some changes in the glibc library, but as far as I know, macOS does not use the glibc library.
There should be a simple way of installing glibc on macOS using Homebrew (brew) as described here, but I get the same error as was mentioned in this question. So apparently currently there is no proper way of doing it and then I am not sure if this will solve my problem.
Is there a solution to this?
The macro makedev is defined in sys/types.h. Just add #include <sys/types.h> into your files. sys/types.h is a header file of Kernel.framework. You should set it in the Clang invocation, like clang -framework Kernel ....
You can also define these macros as they are defined in sys/types.h:
#define major(x) ((int32_t)(((u_int32_t)(x) >> 24) & 0xff))
#define minor(x) ((int32_t)((x) & 0xffffff))
#define makedev(x, y) ((dev_t)(((x) << 24) | (y)))
My project is using some libs of libavcodec on Visual Studio 2010.
After updating the libs (replacing the lib and includes from Libav) and resolving all Compiler Errors (after 3 years a few things changed in libavcodec), the project compiles without a problem, but my compiled dll does not work.
I am 99% sure it is some dependency problem. Sure i did not only update the linked libs of my project but also placed the correct new dlls into the build folder.
The strange thing i have never seen is that dependency walker detects totally wrong imports from the different dlls, see image.
As you can see, all linked libs seem to indicate the same imports - functions that those libs just don't export.
The only thing i do in that direction besides specifying the libs in the linker section is including the .h files in my program and then of course use them heavily;-)
extern "C" {
#include <libavcodec/avcodec.h>
#include <libavutil/opt.h>
#include <libavutil/imgutils.h>
#include <libavformat/avformat.h>
#include <libswscale/swscale.h>
#include <libswresample\swresample.h>
}
What i tried:
Make sure the correct libs and headers are used by the project
clean the build path, tried debug und release build
checked if there are new includes that i may have forgotten to link (this would have ended up in a compiler errror anyways)
restart VStudio
built a test program that links to the same dlls, there the correct imports are shown automatically
compiled with VS 2013, no change at all
Custom building binaries depending upon your current project settings is key to avoiding annoying linker errors like the one your are facing.
You can use vcpkg.exe from github to build the ffmpeg project and rebuild binaries for x86 or x64 machine.
After installing vcpkg on your system, goto to the Powershell prompt and enter .\vcpkg install ffmpeg. After completion of installation enter ".\vcpkg integrate install" so that your latest ffmpeg libraries are available for use.
I'm trying to compile a simple Boost Wave example and while Xcode is recognizing the headers, it is giving me a slew of Apple Mach-O Linker(Id) Errors. I have encountered this before and I don't remember how I solved it. Please help!
I have attached a screenshot.
P.S. I have Boost 1.57.0 and it works just fine with any Xcode Project. For whatever reason, though, it isn't in the case when it involves the header boost/wave.hpp like so...
#include <boost/wave.hpp>
Also, I ruled out the body of the code as a culprit. This throws the linker erros:
#include <boost/wave.hpp>
int main() { return 0; }
Other Boost headers like these, do not:
#include <boost/function.hpp>
int main() { return 0; }
I figured it out, but have no idea why this is the case. If anyone would like to add an explanation, that would be splendid. I had to manually add the various dynamic and static libraries referenced in each of the above issues. I attached a new screenshot so others having this issue can see the end result.
Well, the explanation is very simple. In order to be able to build your project, the compiler working under the hood needs to know:
Where to search for the #include <..> within your project's files: this corresponds to the -I directory option for the g++ compiler. In Xcode this corresponds to set the "Header Search Paths" in the Build Settings of you project.
Without specifying the Header Search Paths, you will get errors on the #include lines since Xcode doesn't know where to look for those included files.
Where to search for the library that must be linked to your source code while building the project: this corresponds to the -L directory option for the g++ compiler. In Xcode this corresponds to set the "Library Search Paths" in the Build Settings of you project.
Without specifying the ** Library Search Paths**, you will get errors while trying to build your project since Xcode doesn't know where to look for the linked libraries.
What libraries must be linked to your project files at compilation time: this corresponds to the -l linking option for the g++ compiler.
In Xcode this corresponds to add the .dylib files to the Link Binary With Libraries in the Build Phases settings of your project. Note that you don't need to add manually the libraries to the main folder of your project, the last described step suffice.
See here and here for the directory and linking options of the g++ compiler, respectively.
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.
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