I'm trying to modify the KMDF vhidmini2 sample from the Windows driver samples on Github (https://github.com/Microsoft/Windows-driver-samples/tree/97cf8edcaddff4fdbc5cc48d56b7d7eb2c39b749/hid/vhidmini2). One of my modifications requires including the hidpi.h header file. When I do this, however, I get compiler errors, the majority of which are:
identifier "USAGE" is undefined
along with a couple of:
redefinition: different type modifiers
as well as a number of syntax errors.
To try and seclude the error, I've tried compiling the vhidmini2 driver (which worked fine), and then inserting the include statement in the vhidmini.h file (which then causes the compilation to fail). Here's the include section of my modified vhidmini.h file; the rest of the code is untouched.
#ifdef _KERNEL_MODE
#include <ntddk.h>
#else
#include <windows.h>
#endif
#include <wdf.h>
#include <hidport.h> // located in $(DDK_INC_PATH)/wdm
#include <Hidpi.h>
#include "common.h"
As an aside, I found a similar problem posted to Stack Overflow here: WDK (Windows Driver Kit) and VC++ headers problem. The solution to this problem seemed to be to tell Visual Studio to load WDK headers before loading SDK headers. The question is a few years old though, and Visual Studio 2015 does not allow the editing of VC++ Directories in the same way. If this is indeed the solution to my problem, how would one go about making this edit in the new Visual Studio? I've tried looking at the property sheets for the project, but the format is completely different.
I managed to fix the problem by replacing the line
#include <Hidpi.h>
with
#include <hidsdi.h>
My guess (based off of a similar problem answered here: Compile error in 'winbase.h') is that hidsdi.h includes in it some things that hidpi.h requires. Therefore, you should either include hidsdi.h before hidpi.h, or only include hidsdi.h. This still seems odd to me though, since the Windows documentation for the structure that I'm using (HIDP_PREPARSED_DATA) says that I only have to include hidpi.h; I wouldn't be surprised if this was a typo (wouldn't be the first time I've seen a typo in the Windows documentation).
Related
I'm trying to compile the bsdmainutils package in Debian that uses the /usr/include/login_cap.h header (from libutil-freebsd-dev), and I'm getting a bunch of errors like this:
/usr/include/login_cap.h:114:62: error: unknown type name ‘rlim_t’;
did you mean ‘__rlim_t’?
rlim_t login_getcapsize(login_cap_t *, const char *, rlim_t, rlim_t);
I'm using Debian testing. Is this a bug in login_cap.h? I see rlim_t defined in /usr/include/x86_64-linux-gnu/bits/resource.h - can I just include that file within login_cap.h? If so, do I have to include the arch-dependent path or does GCC do something special and let me do like #include <sys/bits/resource.h>?
Well, to partially answer my question, this issue is resolved by adding #include <sys/resource.h> to login_cap.h. So, maybe either login_cap.h needs to come like this or bsdmainutils needs to include sys/resource.h.
I made a Debian bug report for this issue here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882728 but I don't know if my solution is correct.
I am trying to compile some source codes about UNIX scokets programs, on Linux I have no problems but on macOS I get stuck in front of types definition problems. I don't know how many details I can put here, but I'll try.
The source codes to be compiled are:
errlib.c
errlib.h
server_test.c
sockwrap.c
sockwrap.h
where the main is located in server_test.c.
To compile I use:
gcc -Wall -DTRACE -o server_test server_test.c errlib.c sockwrap.c
There are no problems running this on Linux, but on macOS I get more than 20 error and all of these are about a (perhaphs) missing definition of bool_t. I suppose something not working in /usr/include/rpc/* files located in macOS internal libraries.
So I looked for if <sys/types.h> is included in /usr/include/rpc/xdr.h and it seems to be not missing.
Some of the first lines of the gcc output are:
In file included from server_test.c:16:
/usr/include/rpc/xdr.h:126:3: error: type name requires a specifier or qualifier
bool_t (*x_getlong)(struct __rpc_xdr *, int *);
^
/usr/include/rpc/xdr.h:126:10: error: function cannot return function type 'int (struct __rpc_xdr *, int *)'
bool_t (*x_getlong)(struct __rpc_xdr *, int *);
^
/usr/include/rpc/xdr.h:128:3: error: type name requires a specifier or qualifier
bool_t (*x_putlong)(struct __rpc_xdr *, const int *);
^
/usr/include/rpc/xdr.h:128:10: error: function cannot return function type 'int (struct __rpc_xdr *, const int *)'
bool_t (*x_putlong)(struct __rpc_xdr *, const int *);
^
/usr/include/rpc/xdr.h:128:3: error: duplicate member 'bool_t'
bool_t (*x_putlong)(struct __rpc_xdr *, const int *);
^
/usr/include/rpc/xdr.h:126:3: note: previous declaration is here
bool_t (*x_getlong)(struct __rpc_xdr *, int *);
^
/usr/include/rpc/xdr.h:136:3: error: type name requires a specifier or qualifier
bool_t (*x_getbytes)(struct __rpc_xdr *, char *, unsigned int);
...
and many others lines that are very similar.
For those who want to deepen, the sources are available here.
What could be the problem?
The bad answer
Issue solved by simply including <rpc/types.h> in the server_test.c source as follows:
#include <rpc/types.h>
The better one
This is a solution above is valid only for this server_test.c implementation.
If you want fix this issue "globally", you can follow follown steps:
disable SIP (how to? here)
get your macOS's xdr.h (from here /usr/include/rpc/xdr.h)
copy it elsewhere two times: one copy is for backup and modify the other one simply adding the required include (#include <rpc/types.h> and see the picture below)
overwrite your modified xdr.h onto the original one in /usr/include/rpc/
re-enable SIP
Here is how I did it:
I am trying to use the following method to include a project header file:
#include FILE_PATH
Where FILE_PATH is defined as the file to be included.
The project compiles without errors if FILE_PATH is include as:
#define FILE_PATH "hal/micro/config.h"
#include FILE_PATH
But if FILE_PATH is pre-defined as a compiler define option inside the project options, then building the project returns the following error:
Error #13: Expected a file name
The development software being used is Code Composer Studio version 6.
What am I missing here to pre-define the header file path in a project?
Additional Details:
I am in the process of converting a working project from the IAR embedded workbench IDE to Code Composer Studio. The Pre-define NAME (--define, -D) shown in the picture below are mostly identical to how they were in the IAR project.
The pre-define name boxed in red is currently the cause of the error, but this could occur with any of the other defines with file pathnames.
I have tried the suggestion of using the #ifdef statement to at least verify that PLATFORM_HEADER is actually defined and it does seem to be defined. I also checked for typos and there doesn't appear to be any noticeable typos.
The key reason for wanting to go with the pre-defined macro approach is to avoid individually making changes to numerous files affected by this error.
I still have not yet tried a command line compile, since I need to reference the manual on how to do so, but I will try as soon as I figure it out.
#StenSoft wrote:
The IDE does not correctly escape the parameters. You should escape the quotes. You can also try placing PLATFORM_HEADER somewhere in the code and see what the compiler would tell you it sees.
I am on OS X 10.10 and trying to build a C 'project' with GLUT and OpenGL.
I reduced it to a minimal example showcasing my problem. I have the following CMakeLists.txt:
cmake_minimum_required(VERSION 2.8)
FIND_PACKAGE(OpenGL REQUIRED)
FIND_PACKAGE(GLUT REQUIRED)
if(OpenGL_FOUND) # never true, but printed as true
link_directories(${OpenGL_LIBRARY_DIRS})
include_directories(${OpenGL_INCLUDE_DIR})
endif(OpenGL_FOUND)
if(GLUT_FOUND)
link_directories(${GLUT_LIBRARY_DIR})
include_directories(${GLUT_INCLUDE_DIR})
endif(GLUT_FOUND)
# print all vars because wtf
get_cmake_property(_v VARIABLES)
foreach(_v ${_v})
message(STATUS "${_v}=${${_v}}")
endforeach()
add_executable(main main.c)
target_link_libraries(main ${GLUT_LIBRARY} ${OPENGL_LIBRARY})
The main.c is just a dummy including two headers:
#include <gl.h>
#include <glut.h>
int main()
{
return 0;
}
Now, cmake . runs fine and for debugging purposes prints all variables. I took the code from somewhere, I do not know enough about cmake to know whether it's doing what I think it is. Anyway, running make returns
main.c:1:10: fatal error: 'gl.h' file not found
#include <gl.h>
^
1 error generated.
The header gl.h is actually present in /System/Library/Frameworks/OpenGL.framework/Headers and as such should be found by cmake, especially since glut.h is in the same structure (simply replace OpenGL with GLUT) and is found just fine. Also, what is confusing to me is that the block in if(GLUT_FOUND)... is never executed (try to put a message statement into it), but among the printed variables it says OPENGL_FOUND=TRUE. But removing the if-condition does not change anything.
The actual question: What the hell is going on? Why does a) cmake not find the header unless specifically included, b) the if-block not execute although OPENGL_FOUND prints as TRUE, c) no such problems occur with glut.h? Spent hours on this and can't fathom why.
It's common to do
#if defined(__APPLE__)
#include <OpenGL/gl.h>
#include <OpenGL/glu.h>
#else
#include <GL/gl.h>
#include <GL/glu.h>
#endif
You can see this being done in one form or another in glfw, glew, sfml and others
I'm surprised that you found OpenGL headers in /System/Library/Frameworks in OS X 10.10. I don't think they have been installed there in quite a few Xcode releases. The most recent header files with Xcode 6.1 on 10.10 should be in:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks/OpenGL.framework/Headers
You don't really need to know this path, unless you want to go look at the headers. I believe the compiler automatically uses the SDK that matches the OS you're compiling on. If for some reason you wanted to build for a different platform, you can override that logic with the -isysroot compiler option.
With header files that come from a framework, the naming you use in your #include statement is:
#include <FrameworkName/HeaderFileName.h>
The compiler will resolve this to the actual pathname of the header within the framework.
Therefore, if you want to use the current OpenGL header, which is gl3.h, from the OpenGL framework, the correct include statement is:
#include <OpenGL/gl3.h>
This will give you access to the Core Profile of the highest supported OpenGL version (which is 3.x or 4.x if you have a reasonably new Mac). Or if you want to use OpenGL 2.1 with legacy features:
#include <OpenGL/gl.h>
As pointed out bei pmr, CMake variables are case-sensitive, so the variable OPENGL_FOUND must be queried.
Also, as PeterT wrote, the header is included as #include <OpenGL/gl.h> on OS X.
I ended up coming to this question after updating qt installed from homebrew and had the same error messages. Going off of Reto's comment, I updated CMAKE_OSX_SYSROOT to /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk and everything went back to working as expected.
I have been having these really odd problems with Visual Studio 2010. At this point, the behavior is so erratic that I really wish I did not have to use it for CUDA (I know I don't have to, but it is hard not to use it).
One of the many problems I have been having with really basic stuff is header files being included more than once. For example:
//vars.cuh
#if !defined(VARS_cuh)
#define VARS_cuh
#include <cuda.h>
#include <cuda_runtime_api.h>
int* kern_xstart, *kern_xend, *kern_ystart, *kern_yend, *kern_zstart, *kern_zend;
/* more variable definitions */
#endif
I then include this file in most of my source files:
//source_file.cu
extern "C"{
#include "vars.cuh"
/* more includes of my own headers */
#include <cuda.h>
#include <cuda_runtime_api.h>
}
/* source file body */
The VS 2010 compiler puts out errors like this: "error LNK2005: foo already defined in other_source_file_I_wrote.cu.obj"
Why is it doing this? Also, to kill two birds with one stone, with this setup, I also have problems with writing a function in source_file.cu, and then prototyping it in vars.cuh. The problem arrises that vars.cuh can't see the definition, even though I am clearly including vars.cuh in source_file.cu!
Thank you!
The header file is being compiled multiple times because, as you say, you include this header file in most of your source files. Those global variables are included in multiple source files and thus are defined in every source file that includes the header. When the linker links all of the object files together, it finds multiple definitions of those variables, hence the error.
If you want to share global variables across multiple source files, declare them as extern in the header, then define each of them once in one source file.
This isn't a problem with Visual Studio or the Visual C++ compiler, it's how C works.