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.
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 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.
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 used the word hierarchy, but I'm not sure if it's the right one! Let me explain.
I have A.h with:
#include <iostream>
#include <vector>
using namespace std;
I have B.h with:
typedef vector<int> int_vector;
int_vector my_function(int x, int y);
Finally I have X.h, which is:
#include "A.h"
#include "B.h"
And X.cpp:
#include "X.h"
// and the rest
But when I compile that with GCC, it says in B.h, vector not defined and so on. Note that this is an example to explain the problem. The project I'm trying to convert to compile on linux compiles perfectly on Windows under Visual Studio.
I could change the files, but it a 300+ files project, so any help or suggestion that would be incredibly efficient ?
There's nothing wrong with the code that you've posted, and it seems unlikely that there would be a bug of this nature in gcc.
More likely the problem isn't what it seems. For example, it could be that there are multiple A.h (or B.h, or X.h) files in your project, and the wrong file is being included somewhere.
My advice would be to run one problematic .cpp file through the preprocessor (gcc -E) and examine the result. That will tell you exactly what is being included when.
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