For my project I'm required to compile my program on both Microsoft Visual Studios (windows) and g++ (unix).
My program works when on windows, but when on g++ I get the following error:
utilities.cpp:4:21: fatal error: windows.h: No such file or directory
#include <windows.h>
I feel like I messed up when separating the header file and utilities.cpp.
For reference here is the globals.h and the utilities.cpp files:
http://imgur.com/a/GhhCl
You can't use <windows.h> on a linux machine
Use ifdef to choose what preprocessor commands run. More specifically, you can check if the operating system is windows with the pre-defined __WINDOWS__ macro. Most compilers
#ifdef __WINDOWS__
#include <windows.h>
#endif
You can also try _WIN32
The reason for your compilation failure has been explained by #NickLamp , but only that macro won't make your program work properly in Xnix.
It seems that you are building CLI interface, and instead of using OS-specific APIs, I recommend you use some cross-platform CLI libraries:
Cygwin + ncurses or pdcurse.
See http://www.cplusplus.com/articles/4z18T05o for details.
Unlike the Java, C and C++ are not platform independent languages. Some of their things like - libraries files, pre-defined objects and functions may vary from one Operating System to another.
If you want to compile your file on Ubuntu, then you will have to either remove the <windows.h> header file from your file or use some techniques (like - macros) which ensure against the use of <windows.h> on the Operating Systems other than Windows. Because this header-file is strictly designed for Windows.
Related
I am porting my c/cpp project from gcc/Linux to Windows using MSYS2/MinGW64 environment. Two of the headers were not found where expected and I had to modify include in the way bellow in order to achieve succesful compilation.
#ifdef __MINGW64__
#include <ncurses/ncurses.h>
#else
#include <ncurses.h>
#endif
and
#ifdef __MINGW64__
#include <json/json.h>
#else
#include <jsoncpp/json/json.h>
#endif
However I feel this solution is not correct (or is it?). I think I probably missed something obvious, may be some configuration step. What can I do better?
BTW: I use simple make file which calls g++ with the same set of parameters in Linux and Windows and I do not specify any paths there.
Thank you in advance!
For jsoncpp, you can run this command on both Linux and MSYS2 to get the recommended compiler flags:
pkg-config --cflags jsoncpp
If you pass those flags to the compiler, then I think a simple #include <ncurses.h> should work on both platforms.
That does not work for ncurses, unfortunately, because there is no configuration file for ncurses /mingw64/lib/pkgconfig/ in MSYS2.
I have 4 files, linuxasm.h linuxasm.cpp windowsasm.h and windowsasm.cpp
in the main.cpp i have
#ifdef __linux
#include "linuxasm.h"
#elif _WIN64
#include "winasm.h"
#endif
the function names in the .cpps are identical
is there a way to prevent GCC from complaining about multiple definitions of functions?
Or should I go about it another way?
You should do it some other way. I would use your build system to omit the appropriate .cpp file from the build based on architecture (if I understand your situation correctly).
Basically, for one target, say Win64, the windowsasm.cpp is a dependency and is compiled; similarly for Linux. Look up how your system is managing dependencies for the build and give it a try.
I'm developing a game engine for Sega Dreamcast and Windows. I have implemented my own library for the Dreamcast hardware, which pretty much does the same thing as OpenGL for PC. Now, I want to merge the two builds into one project, so I don't need to dev to different project doing the exact same high level stuff.
I know you can add a preprocessing line like this: #define DREAMCAST, and then the Dreamcast headers will be included and the appropriate low level function will be called instead of OpenGL. This has been done before, but I don't know how to make that possible.
This has really nothing to do with Dreamcast, it could be Mac, Linux or whatever. I have different compilers for each platform. So when #define DREAMCAST, I want the G++ KOS compiler to include the Dreamcast-specific headers and classes. If #define DREAMCAST is not present, I want MingGW to include the Windows OpenGL headers and classes.
How can I do this?
For the initial problem of including different versions depending on a predefined symbol, a simple solution is available:
#if defined(DREAMCAST)
#include <my_dreamcast_header>
#else
#include <opengl_header>
#endif
This functionality should be available on just about any C or C++ compiler - and it definitely is on MinGW. You still need to invoke the correct compiler yourself of course, as there is no way to change the compiler once compilation starts.
When i compile my C++ solution in vs2010 x64 mode, i get the below compilation issue.
Can not open include file 'sys/param.h' :No such file or directory.
But the same compiles fine in Win32 mode.
I am not sure how this header file is missing.Can any one help me on this?
I am using some of the client headers and this is the below code section that is present in the client file.
#ifndef WIN32
#include <sysipc.h>
#include <sys/param.h>
#endif
The include #include <sysipc.h> should be #include <sys/ipc.h>, however, this is a POSIX header file that is meant for Linux build projects so it won't work for any Visual Studio projects. Since you're compiling for x64, WIN32 flags might not be set by default.
Try changing the macro to:
#ifndef _MSC_VER
#include <sys/ipc.h>
#include <sys/param.h>
#endif // !_MSC_VER
Hope that helps.
This is highly likely a consequence of some #if going wrong - e.g. it's checking for _M_IX86, and it not being set on a 64-bit system, it picks up something non-windows and tries to compile that.
sys/param.h is a unix/linux header-file, and you shouldn't expect to find that in your Windows system. [edit: unless you hooked in a version of the GNU compiler or did some other modification to the compilation tools core of your MSVC build environment]
Unfortunately, without seeing the source code, all we can possibly do is explain the possible reasons...
I have some .h files as follows (on Linux)
Source/Server/connect.h
Source/Server/message.h
...
I am developing another application that needs the two .h files but is in a different directory
Source/App2/..
How can I include the connect.h file in the App2 application, considering that I use perforce and everyone else working on the application would have their own copy so adding an absolute path to the include library might not be a good idea but im not sure.
EDIT:
I use a proprietary build mechanism for building the code so will not be able to specify gcc options directly.
You can #include a relative path to the files:
#include "../Server/connect.h"
or you can add a flag to tell the compiler to look in the other directory. For gcc you can use -I../Server; for Visual C++ you can use /I"../Server"; other compilers, I'm sure, have their own flags for this purpose.
I think the second is better in most cases, since it allows you to move your projects around while only requiring you to modify the include path in one place (the makefiles or property sheets).
What about adding include search path to he compiler, for gcc it's -I switch.
I suggest removing paths from the #include statements. As others have stated, put the paths into the parameters to the compiler. Resolve the path differences in the makefile or use environment variables (may need to do both).
My experience is that files will move. Anything that doesn't use relative paths will break the build (which is very bad).
in addition static relative paths, you can also play with preprocessor chicanery. One technique I saw used at Adobe for cross-platform code, was to do something like this:
/* globalplatform.h */
#ifdef MAC
#define PLATFORM "../Platform/Mac/MacPlatform.h"
/* custom standard IO etc */
#define STDIO "../Platform/Mac/io/stdio.h"
#define CTYPE "../Platform/Mac/io/ctype.h"
#endif
#ifdef WIN32
#define PLATFORM "../Platform/Win/WinPlatform.h"
#define STDIO <stdio.h>
#define CTYPE <ctype.h>
#endif
/* etc */
#ifndef PLATFORM
#error undefined PLATFORM
#endif
/* some C file */
#include "globalplatform.h"
#include PLATFORM
#include STDIO
/* don't need CTYPE, no penalty */
While the platform problem isn't your problem, you can define the relative paths based on build configuration if you want to and the config changes happen in one place instead of many and client files only pull in what they need. The down side is that any tools you use for browsing header files (right-click and so on) are hosed.
You can change the compiler directives as above, or modify the path within your code (either relative or absolute).
I would suggest that you consider the best locations for headers and object files (and libraries) for all your projects and set that up.
If you have standard include and lib locations you'll simplify the development down the road