Leaderboard

Most Brians I've met are pretty cool, but those shifty Bryans on the other hand I wouldn't be to sure about.

My understanding from what came up is that Matlab is attempting to build a wrapper dll with some more matlab friendly interface. A quick google didn't find me anything about how it does this, but that seems to be what its doing. I say that because the "we dont know the..." come from the labview headers. So it seems like Matlab is running a compiler against stim.h which includes the platdefines header, and since I'm assuming the matlab compiler is not one of the ones NI was expecting when they built this (or if matlab simply doesn't #define the same definitions NI is expecting), the compiler correctly spits out the errors shown, as in this snippet of platdefines: #ifdef _M_PPC #define ProcessorType kPPC #elif defined(_M_IX86) #define ProcessorType kX86 #elif defined(_M_X64) #define ProcessorType kX64 #elif defined(_M_ALPHA) #define ProcessorType kDECAlpha #elif Compiler == kBorlandC #define ProcessorType kX86 #elif defined(_ARM_) #define ProcessorType kARM #else #error "We don't know the ProcessorType architecture" #endif So the question becomes what should it be. My guess is that they should be defined per the labview exe/dll which is why I suggested the MSVC compiler definitions (as I understand it, this is what NI uses for windows builds). However it may be that the right answer is to edit the headers to set something more appropriate. For example, in the section above, you could comment every line out except for "#define ProcessorType kX64". Similarly you could comment out the compiler section and replace it with "#define Compiler kGCC" (if that is what matlab uses, which I assume it is). The only reason these need to be defined is so that extcode.h picks up all the appropriate definitions and headers for the platform. For example. stim.h uses the type "uint32_t". This is defined in stdint.h, but if your compiler isn't including it already then stim.h can't be compiled. So, in fundtypes.h, it has a bunch of platform checks to see if it needs to define those types. The easier route, vs trying to make extcode.h have the proper types, would be to just edit stim.h directly to include the type definitions you need. I would suggest editing your stim.h to look like this (lines 1-7): //#include "extcode.h" //this dll only uses two uncertainly defined types, but they are defined by stdint.h. This section is borrowed from fundtypes.h #if !defined(_STDINT_H_) && !defined(_STDINT_H) && !defined(_STDINT) #include <stdint.h> //alternatively comment the line above and uncomment these lines: //typedef int int32_t; //typedef unsigned int uint32_t; #endif #ifdef __cplusplus extern "C" { #endif .....