I am trying to include 2 platform-specific stdafx.h files in my .cpp file, but the compiler is unhappy when I try to #ifdef it.
#ifdef _WIN32
#include "stdafx.h"
#elif _MAC
#include "MAC/stdafx.h"
#endif
You may wonder why I am using stdafx.h in the Mac code, but that is not important at the moment :).
When I try to compile the code on Windows, I receive: Fatal Error C1018. I tried enclosing other header files with #ifdef in the same file, and the compiler was happy. Therefore, it looks like Windows doesn't like stdafx.h to be #ifdef-ed, or that Windows only allows #include stdafx.h
to be the first line in the file.
So my question is, why?
Kat
When the compiler includes a pre-compiled header, it basically "forgets" anything that came before the header. Thus your #elif isn't matched to a #if anymore.
This is because you have Precompiled Headers turned on - turn it off and you should be fine.
Related
I downloaded LLVM (12.0.1) from the script file llvm.sh which they have now started to include on their Debian downloads page.
Ran clang and everything was working as expected(good job dev team I guess?).
The installation script installed LLVM in /usr/lib/LLVM-12/ and /usr/include/LLVM-12/ (these had some .h files)
So I tried writing some passes; created an out-of-tree build using the answer given here:
Facing issue with makefile for Hello pass in llvm
But when I ran the make, it gave me this error:
/usr/include/llvm-12/llvm/Pass.h:337:10: fatal error: llvm/PassAnalysisSupport.h: No file or directory
337 | #include "llvm/PassAnalysisSupport.h"
|
compilation terminated.
So I checked /usr/include/llvm-12/llvm/ and found that Pass.h and PassAnalysisSupport.h both were present in the current directory, so shouldn't the Pass.h file have #include "PassAnalysisSupport.h" instead of the present #include "llvm/PassAnalysisSupport.h"?
I also checked the code for Pass.h online and it also had #include "llvm/PassAnalysisSupport.h". Other header files in the llvm directory also used the same format #include "llvm/<name>"
So what is going on here, who messed up, the devs or my llvm.sh (also the devs) or the problem is something else?
Any help would be appreciated (Im using Mint MATE 20.2 if thats relevant)
Source file (headers; firstpass/first/fpass.cpp):
#include <llvm-12/llvm/Pass.h>
#include <llvm-12/llvm/IR/Function.h>
#include <llvm-12/llvm/Support/raw_ostream.h>
#include <llvm-12/llvm/IR/LegacyPassManager.h>
#include <llvm-12/llvm/Transforms/IPO/PassManagerBuilder.h>
(firstpass/CMakeLists.txt):
find_package(LLVM REQUIRED CONFIG)
include_directories($(LLVM_INCLUDE_DIRS))
add_subdirectory(first)
(firstpass/first/CMakeLists.txt):
add_library(LLVMfirst MODULE fpass.cpp)
I am trying to compile a simple CLR project, which has no dependency.
When I compile this project I get 973 warnings (C4945) stating that
c:\windows\microsoft.net\framework\v4.0.30319\system.dll : warning C4945: 'xxx' : cannot import symbol from 'c:\windows\microsoft.net\framework\v4.0.30319\system.dll': as 'xxx' has already been imported from another assembly 'System'
As I mentioned that my project has no dependency on other projects, I tried to compile my cpp files one by one, starting with stdafx.cpp.
While doing this I noticed that if I include #include <msclr\marshal.h> I get those warnings, and if I don't there are no warnings.
Now I have following queries.
Is #include <msclr\marshal.h> deprecated and replaced by something
else?
If no, how can I remove those warnings? Is #pragma warning disable the only way?
This is still a problem for VS2019, but you can force the header to skip #using <System.dll> like this:
#pragma push_macro("_CRT_WINDOWS")
#define _CRT_WINDOWS
#include <msclr\marshal.h>
#pragma pop_macro("_CRT_WINDOWS")
This works for the other marshal headers as well (marshal_cppstd.h, etc.)
libxml uses the following line of code in libxml.h but it doesn't come bundled with libxml.
#include "config.h"
I'm trying to use XMPPFramework for Objective-C, in Swift. The XMPPFramework has libxml as a dependency.
You could try including these:
#include <stdio.h>
#include <libxml/tree.h>
#include <libxml/parser.h>
As found on:
http://wiki.xmlsoft.org/The_libxml2_Library#Installing
Sorry in advance for a kind-of-dumb question - I'm pretty new to all this.
So I downloaded asio from here, and tried to #include asio.hpp, but got the following error;
fatal error: boost/config.hpp: No such file or directory
I thought this was rather odd, as it was suppose to be independent of Boost. I poked around a bit, and saw that I needed to define ASIO_STANDALONE, which I promptly did, only to be met with more errors where it tried to #include something else from Boost.
Is there just a big list of all the things I have to #define to tell it to be standalone or something? That would be very helpful.
This is an old question, however i had the same problem currenlty with Visual Studio 2013 and Asio 1.10.6. In Visual there is no switch nor compiler flag for c++11 features. Even with #define ASIO_STANDALONEAsio requires Boost.
Solution is to manually specify that our compiler is c++11 compliant. Just add:
#define ASIO_STANDALONE
#define ASIO_HAS_STD_ADDRESSOF
#define ASIO_HAS_STD_ARRAY
#define ASIO_HAS_CSTDINT
#define ASIO_HAS_STD_SHARED_PTR
#define ASIO_HAS_STD_TYPE_TRAITS
#include <path_to_asio/asio.hpp>
As noted on the Asio website:
When using a C++11 compiler, most of Asio may now be used without a dependency on Boost header files or libraries. To use Asio in this way, define ASIO_STANDALONE on your compiler command line or as part of the project options.
Thus even when ASIO_STANDALONE is defined, Asio will use Boost when:
Using a non-C++11 compiler.
When using certain features, such as stackful coroutines that are based on the Boost.Coroutine library.
With asio-1.10.2, the following program:
#include <asio.hpp>
int main()
{
asio::io_service io_service;
}
compiles with gcc 4.8.1, using -DASIO_STANDALONE -std=c++11 compiler flags. Without specifying the compiler to use c++11, compilation fails when attempting to include Boost header files.
I have an XCode project with objective-C files. If I add a new (empty) C file and try to build, I get a large number of errors right away while building a precompiled header, in ProcessPCH step. The errors are "fatal error: Could not build module 'Foundation'", and things in Foundation.h not being found. Remove the C file and it builds again. What is going on, and how to fix it?
(XCode 5.0, OSX 10.8.4)
EDIT I have tried Clean and Clean build folder, no effect.
EDIT Setting Precompile prefix header = No results in a bunch of syntax errors instead, in stuff like NSObject.h (and other Foundation framework header).
EDIT User Cy-4AH figured it out: there needs to be #ifdef __OBJC__ around the whole pch file.
Surround #import's with preprocessor directive #ifdef __OBJC__ #endif