Am facing a problem in resolving dependencies in C,
config.h file is as follows,
...
....
/* MACRO */
/* #undef MACRO */
....
....
And a file example.c contains,
...
#ifdef MACRO
#include "../../sample_header.h"
#endif
...
while resolving dependencies, the compiler is trying to resolve the sample_header.h file even though the "MACRO" is not enabled. Its very weird. Could anyone help on this issue.
The issue is resolved. The problem i forgot to do "autoreconf" after making changes in configure.ac file. So whenever any change is done in configure.ac "autoreconf" has to be done.
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.)
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
Is there a way to forcefully set the release mode of swig modules in cmake to build in release mode no matter what the actual build type is?
I am trying to build a python module using swig autogenerated code, and it complains of a python debug library when I build my application in debug mode.
I am not interested in debugging python module related code, so I am fine with not building the swig autogenerated python modules in debug mode.
Here is what I have in my cmakelists.txt file:
set_source_files_properties(abstract.i PROPERTIES CPLUSPLUS on)
swig_add_module(${PROJECT_NAME} python abstract.i)
swig_link_libraries(${PROJECT_NAME} ${PROJECT_NAME} ${PYTHON_LIBRARIES})
I suppose the real issue is that MSVC produces link error, due to the missing "python_d.lib"
Just insert into the header of SWIG interface (your *.i) files:
%begin %{
#ifdef _MSC_VER
#define SWIG_PYTHON_INTERPRETER_NO_DEBUG
#endif
%}
... and remove
#ifdef _MSC_VER
...
#endif
when the issue is generic, not MSVC related only
Hmm, how about wrapping your code snippet in
set(CMAKE_TMP_BUILD_TYPE ${CMAKE_BUILD_TYPE})
set(CMAKE_BUILD_TYPE "Release")
and
set(CMAKE_BUILD_TYPE ${CMAKE_TMP_BUILD_TYPE})
?
You can tell CMake not to include a project in the default build of a certain configuration. For example, for a Python module (with the underscore added to the target by SWIG):
SET_TARGET_PROPERTIES(_${PROJECT_NAME} PROPERTIES EXCLUDE_FROM_DEFAULT_BUILD_DEBUG True)
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.