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...
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.
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.
I am working on a C++ project using Xcode on MacOS X, and am now starting to port it to Linux using the Code::Blocks IDE.
Many of my source files are in separate directories and I am having issues including them.
Here is an example of this issue:
folder1/foo.h
folder2/dog.h
foo.h includes dog.h with: `#include "dog.h"`
It works fine on Xcode if both files in the same project but if I try it in Code::Blocks it has an error finding it.
I can fix this issue in Code::Blocks by changing the code to use a relative include path such as:
#include "../folder2/dog.h"
Unfortunately doing this stops Xcode from being able to find the file.
How can I fix this issue so I can compile the same code in multiple IDEs? I would like to avoid throwing all the source in the same folder. Should I use a preprocessor statement similar to:
#if XCODE
#include "dog.h"
#else
#include "../folder2/dog.h"
#endif
Rearrange your structure so that one project has only one common include directory:
/project/
/src/*.cpp
/include/*.hpp
/folder1/dog.hpp
/folder2/cat.hpp
Now say #include <config.hpp> and #include <folder1/dog.hpp> etc., and add to your compiler flags:
-I ${PROJECT_DIR}/include
How a given compiler/IDE locates dependencies is, unfortunately, entirely compiler/IDE-specific. There is no way to arrange this in such a way that it will be honoured by all development environments.
I don't know Xcode or Codeblocks, but I'm sure there must be some project configuration that controls where they looks for #include files.
I am including a third party header and source file into my project.
At the top of the header there is this:
#if defined(WIN32) || defined(WIN16)
#ifndef MSDOS
#define MSDOS
#endif
#endif
#include <stdio.h>
#include <stdlib.h>
#ifndef MSDOS
#include <unistd.h>
#endif
#include "des.h"
The problem is that #if defined(WIN32) fails and the compilation fails when trying to #include unistd.h which I don't want to do.
I have third party project that works with this header file i.e. WIN32 is defined and it doesn't try to include In Visual Studio I did "Go To Definition" on "WIN32" and was taken to the following definition in WinDefs.h.
#define WIN32
I'm not sure this is where its getting WIN32 definition from, as the third party project does not appear to include "WinDefs.h".
So my problem is, how can I get WIN32 to be defined in my current new project?
Depends on your project setup. WIN32 is defined inside the windows header files, but you can pass it to the compiler as well ("-DWIN32" for gcc for example). Try it and see whether it compiles.
Visual Studio has the built-in define _WIN32. mingw-gcc has WIN32 and _WIN32 built-in so the project was likely tested using gcc. You might add
#if defined(_WIN32) && !defined(WIN32)
#define WIN32
#endif
or just add a -DWIN32 to the CFLAGS.
Check your includes. I am guessing that the third party header is included prior to the windows.h. So, in your main.cpp or equal it should be
#include <windows.h> // this will also include windefs.h
#include <thirdParty.h>
and not the other way around.
Hope that helps.
You can simply include the windows header files (windows.h) before including the third party header - as you already found out WIN32 is defined there but technicaly it could be defined anywhere (so if the third party project is not including the windows headers check if it's being defined in the compiler project settins directly).
BTW there is also a _WIN32 define that is set by the compiler, it's possibly a better idea to look for this define if checking if the code is being compiled under windows;
For those seeking answers to the
where is WIN32 defined
part of the questions, I've found it defined in:
minwindef.h
ole2.h
Note, I have no confidence that these are the only places it's defined. I expect there are probably other files where it's defined. Nevertheless, I thought this might help some people.
Some WIN32 defined in the compiler . Just like this，If you use the gcc for windows , WIN32 is defined . If you use the gcc for linux , WIN32 is not defined :)
So , the macros is a switch. You can define it to use somethine , and not define it to unuse something.
I have a Visual Studio C++ based program that uses pre-compiled headers (stdafx.h). Now we are porting the application to Linux using gcc 4.x.
The question is how to handle pre-compiled header in both environments.
I've googled but can not come to a conclusion.
Obviously I want leave stdafx.h in Visual Studio since the code base is pretty big and pre-compiled headers boost compilation time.
But the question is what to do in Linux. This is what I found:
Leave the stdafx.h as is. gcc compiles code considerable faster than VC++ (or it is just my Linux machine is stronger ... :) ), so I maybe happy with this option.
Use approach from here - make stdafx.h look like (set USE_PRECOMPILED_HEADER for VS only):
#ifdef USE_PRECOMPILED_HEADER
... my stuff
#endif
Use the approach from here - compile VC++ with /FI to implicitly include stdafx.h in each cpp file. Therefore in VS your code can be switched easily to be compiled without pre-compiled headers and no code will have to be changed.
I personally dislike dependencies and the mess stdafx.h is pushing a big code base towards. Therefore the option is appealing to me - on Linux you don't have stdafx.h, while still being able to turn on pre-compiled headers on VS by /FI only.
On Linux compile stdafx.h only as a precompiled header (mimic Visual Studio)
Your opinion? Are there other approaches to treat the issue?
You're best off using precompiled headers still for fastest compilation.
You can use precompiled headers in gcc as well. See here.
The compiled precompiled header will have an extension appended as .gch instead of .pch.
So for example if you precompile stdafx.h you will have a precompiled header that will be automatically searched for called stdafx.h.gch anytime you include stdafx.h
Example:
stdafx.h:
#include <string>
#include <stdio.h>
a.cpp:
#include "stdafx.h"
int main(int argc, char**argv)
{
std::string s = "Hi";
return 0;
}
Then compile as:
> g++ -c stdafx.h -o stdafx.h.gch
> g++ a.cpp
> ./a.out
Your compilation will work even if you remove stdafx.h after step 1.
I used option 3 last time I needed to do this same thing. My project was pretty small but this worked wonderfully.
I'd either go for option 4 or option 2. I've experimented with precompiled headers on both various VS versions and GCC on Linux (blog posts about this here and here). In my experience, VS is a lot more sensitive to the length of the include paths, number of directories in the include path and the number of include files than G++ is. When I measured build times properly arranged precompiled headers would make a massive difference to the compile time under VS whereas G++ was pretty much unimpressed by this.
Actually, based on the above what I did the last time I worked on a project where this was necessary to rein in the compile time was to precompile the equivalent of stdafx.h under Windows where it made sense and simply used it as a regular file under Linux.
Very simple solution.
Add a dummy file entry for "stdafx.h" in Linux environment.
I would only use option 1 in a big team of developers.
Options 2, 3, and 4 will often halt the productivity of other members of your team, so you can save a few minutes a day in compile time.
Here's why:
Let's assume that half of your developers use VS and half use gcc.
Every now and then some VS developer will forget to include a header in a .cpp file.
He won't notice, because the stdafx.h implicitly includes it. So, he pushes his changes in the version control, and then a few other members of the gcc team will get compiler errors.
So, for every 5 minutes-a-day you gain by using precompiled headers, 5 other people waste by fixing your missing headers.
If you don't share the same code across all of your compilers, you will run into problems like that every day. If you force your VS developers to check for compilation on gcc before pushing changes, then you will throw away all your productivity gains from using precompiled headers.
Option 4 sounds appealing, but what if you want to use another compiler at some point in time ? Option 4 only works if you only use VS and gcc.
Notice that option 1 may make gcc compilation suffer a few seconds. Although it may not be noticeable.
It's simple, really:
Project->Project Settings (Alt + F7)
Project-Settings-Dialog:
C++ -> Category: Precompiled Headers -> Precompiled Headers radio buttons --> disable
Since stdafx.h is by default all the Windows-specific stuff, I've put an empty stdafx.h on my other platform. That way your source code stays identical, while effectively disabling stdafx on Linux without having to remove all the #include "stdafx.h" lines from your code.
If you are using CMake in your project, then there are modules which automate it for you, very convenient, for example see cmake-precompiled-header here. To use it just include the module and call:
include( cmake-precompiled-header/PrecompiledHeader.cmake )
add_precompiled_header( ${target} ${header} FORCEINCLUDE SOURCE_CXX ${source} )
Another module called Cotire creates the header file to be precompiled (no need to manually write StdAfx.h) and speeds up builds in other ways - see here.
I've done both option 2 (#ifdef) and option 4 (PCH for gcc) for cross platform code with no issues.
I find gcc compiles much faster than VS so the precompiled headers are generally not that important, unless you are referencing some huge header file.
I have a situation where #2 in particular didn't work for me (There are numerous VS build configs where a #ifdef around #include "stdafx.h" does not work). Other solutions were suboptimal because the files themselves were cross-project as well as being cross-platform. I did not want to force preprocessor macros to be set or force linux or even windows builds to use (or not use) pch, so...
What I did, given a file named notificationEngine.cpp, for example, was removed the #include stdafx.h line entirely, created a new file in the same directory called pchNotificationEngine.cpp with the following contents:
#include "stdafx.h"
#include "notificationEngine.cpp"
Any given project can just include the correct version of the file. This admittedly is probably not the best option for cpp files that are only used by a single project.