There are two h-files in which the data type is defined:

  • in the first case (wintypes.h) as typedef unsigned long DWORD;
  • in the second (stdafx.h) as typedef uint32_t DWORD, LPDWORD;

The first data type (the wintypes.h file) is needed for functions in the xxx.cpp file being compiled. On the same xxx.cpp, Crypto.h, having #include "stdafx.h" , is connected, and winscard.h, having #include "wintypes.h" . When compiling for Ubuntu, an error occurs:

 In file included from Crypto.h:27:0, from xxx.cpp:12: stdafx.h:29:26: error: conflicting declaration 'typedef uint32_t* LPDWORD' typedef uint32_t DWORD, *LPDWORD; ^ In file included from winscard.h:21:0, from xxx.cpp:11: wintypes.h:78:17: note: previous declaration as 'typedef DWORD* LPDWORD' typedef DWORD *LPDWORD;

Do not judge strictly, I am still just learning, I may not know much. Please explain how to fix it.

  • Uh ... do you compile Windows sources for Ubuntu? - Harry
  • @Harry, this project was written for iOS. It needs to be compiled under Linux. I understand that win **. H will compile, but will not work under linux? Explain what I am doing wrong? - VadoM

1 answer 1

If the DWORD uint32_t , then there should be no problems. But since they are, it turns out that this is not so. To abuse the compiler on conflicting declarations it was not necessary to remove this conflict. For example, add a conditional compilation directive in one of the files:

 #ifdef WIN32 typedef DWORD* LPDWORD; #else typedef uint32_t* LPDWORD; #endif

It makes sense to specify the actual values ​​of defines and types according to the situation. In your situation, it seems that the files are simply not adapted for building under different platforms as part of a single module.

  • thanks for the answer! I tried, but it turns out that for some files you need a typedef uint32_t DWORD, and for others, typedef unsigned long DWORD. - VadoM
  • one
    The @VadoM thing is that the actual size of types like unsigned long not standardized. And on different systems may be different. And uint32_t is always a 32-bit unsigned type. Moreover, it is not even obligatory for existence in a particular compiler. In that situation, when the code is assembled just unsigned long coincides with uint32_t , that's all (although maybe this branch is not used at all in the code, that is, there are already other #ifdef excluding redefinitions). You can still get acquainted with the answer for educational purposes. - αλεχολυτ
  • thank! I'll try to figure it out - VadoM