Intel C++ compiler and cannot open stdarg.h on OS X - xcode

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.

Related

Error "fatal error: 'sys/sysmacros.h' file not found"

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)))

CUDA error with Boost make_shared.hpp? [duplicate]

I'm trying to integrate CUDA to an existing aplication wich uses boost::spirit.
Isolating the problem, I've found out that the following code does not copile with nvcc:
main.cu:
#include <boost/spirit/include/qi.hpp>
int main(){
exit(0);
}
Compiling with nvcc -o cudaTest main.cu I get a lot of errors that can be seen here.
But if I change the filename to main.cpp, and compile again using nvcc, it works. What is happening here and how can I fix it?
nvcc sometimes has trouble compiling complex template code such as is found in Boost, even if the code is only used in __host__ functions.
When a file's extension is .cpp, nvcc performs no parsing itself and instead forwards the code to the host compiler, which is why you observe different behavior depending on the file extension.
If possible, try to quarantine code which depends on Boost into .cpp files which needn't be parsed by nvcc.
I'd also make sure to try the nvcc which ships with the recent CUDA 4.1. nvcc's template support improves with each release.

MEX compile error: unknown type name 'char16_t'

I cannot compile any MATLAB MEX code due to the following error:
In file included from /Applications/MATLAB_R2013a.app/extern/include/mex.h:58:
In file included from /Applications/MATLAB_R2013a.app/extern/include/matrix.h:294:
/Applications/MATLAB_R2013a.app/extern/include/tmwtypes.h:819:9: error: unknown type name 'char16_t'
typedef char16_t CHAR16_T;
The only thing that has changed on my machine as far as I can remember is that Xcode was updated to version 5.1 (5B130a).
Any fix for the time being to compile MEX code in MATLAB?
[Running on OS 10.9.2 with Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)]
By default, the upgraded Clang doesn't set char16_t, which is required by MATLAB.
Quick fix
This works for C or C++ code but needs to be done on each mex command line.
>> mex -Dchar16_t=uint16_t ...
Other solutions below put this definition into the mex configuration or enable C++11.
Permanent solution
Options:
Add -std=c++11 to CXXFLAGS in your mex configuration file AND compile .cpp files instead of .c. The mex config file is mexopts.sh (pre-R2014a) or the .xml file indicated by mex -setup (R2014a+). This is what worked for OP, but the next option works too. Be sure to edit the active/installed config, not the system-wide reference. Try the next solution if you can't tell.
Use a #define or typedef to create char16_t before including mex.h (see "other workaround" below).
In some future version of MATLAB, this will have been fixed. Re-run mex -setup to have MATLAB reconfigure it for you and it works. As of R2014a, this doesn't do the trick.
As a last resort, you can always modify the MATLAB installation, hacking MATLAB's tmwtypes.h as Dennis suggests, but I strongly suggest NOT modifying the MATLAB installation.
Note: If you are using C and cannot or don't want to change to C++, follow the solution in this other answer, OR see the alternative workaround below.
The other workaround
If for some reason you are not able to enable the C++11 standard, you can use the preprocessor to define char16_t. Either put #define char16_t uint16_t before #include "mex.h", or set it with the compiler command line:
-Dchar16_t=uint16_t
Alternatively, use a typedef, again before including mex.h:
typedef uint16_t char16_t;
If these solutions don't work, try changing uint16_t to UINT16_T. Further yet, others have reported that simply including uchar.h brings in the type, but others don't have that header.
I experienced the same error, also directly after upgrading to Xcode 5.1.
The relevant lines (818-824) in the file tmwtypes.h, which causes the error, are:
#if defined(__STDC_UTF_16__) || (defined(_HAS_CHAR16_T_LANGUAGE_SUPPORT) && _HAS_CHAR16_T_LANGUAGE_SUPPORT)
typedef char16_t CHAR16_T;
#elif defined(_MSC_VER)
typedef wchar_t CHAR16_T;
#else
typedef UINT16_T CHAR16_T;
#endif
A solution is to simply change the line
typedef char16_t CHAR16_T;
into
typedef UINT16_T CHAR16_T;
A must admit that I don't know if this affects any function or behaviour of mex files but at least I'm able to compile my c files again using mex.
Please see other answers if this method doesn't work.
I upgraded my gcc/g++ compilers using homebrew to version 4.8 --> gcc-4.8 and g++-4.8.
After that I changed the following lines in the mexopts.sh file:
CXXFLAGS="-fno-common -fexceptions -arch $ARCHS -isysroot $MW_SDKROOT -mmacosx-version-min=$MACOSX_DEPLOYMENT_TARGET -std=c++11"
In my mexopts.sh, this is line 150. I only added the -std=c++11 flag which is what I guess chappjc meant.
EDIT: This is covered in the update by chappjc!
I just add my own experiment (C++ only). The
#define char16_t uint16_t
was causing some problem in the other parts of the mex file. In fact, subsequently to my mex file, char16_t was properly defined. By tracking the chain of includes, the proper type char16_t is set in a file named __config :
typedef __char16_t char16_t;
which is also the first file included from <algorithm>. So the hack consists in including algorithm before mex.h.
#include <algorithm>
#include "mex.h"
and the proper settings are performed, still in a multiplatform manner and without changing anything in the build configuration.
Include uchar.h before including mex.h...works fine. Also, the answer above (adding -std=c++11) only works for c++, not c.
#include <uchar.h>
#include "mex.h"
As part of XCode 5.1.1 char16_t is defined in __config, which is called from typeinfo.
You can add
#include <typeinfo>
before
#include "mex.h"
to have char16_t defined.
This post might help: http://www.seaandsailor.com/matlab-xcode6.html
It was easier than I thought. Just replace all 10.x with your OS X version and add -Dchar16_t=UINT16_T to CLIBS in mexopts.sh file.
It worked on OS X 10.9 Mavericks with Xcode 6 installed.

Compile errors with #include <string> in Cocoa App

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

Xcode Intel compiler icc cannot find #include <algorithm>

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.

Resources