Jump to content
News about the LabVIEW Wiki! Read more... ×
farzane lk

"We don't know the Compiler" Error from platdefines.h in Matlab

Recommended Posts

Hello

I have received a LabVIEW dll and the corresponding header files so that I can send a trigger to a skin stimulation device.

when I use the loadlibrary command in my Matlab script, I receive these two errors:  "We don't know the Compiler" and "We don't know the ProcessorType architecture"

Which means while reading the "platdefines.h", the Compiler and the ProcessorType does not match the ones listed in ifs.
I have set c++ compiler to visual studio 2015 in Matlab. (also tried MinGW). the system I`m using is Windows 10 (tried on 7, too), 64bit.

I read somewhere that manually defining the ProcessorType and the compiler might solve the issue. But the problem is I Don`t know what they are. (when these two conditions below are not accepted.)

#elif defined(_MSC_VER) || defined(_NI_VC_)
        #define Compiler        kVisualC

#elif defined(_M_X64)
        #define ProcessorType    kX64

--------------------------------------------------

How should I find out the ProcessorType and the compiler I have? 
I`d be EXTREMELY THANKFUL for any solutions you can think of.

P.S.1 I attached all the headers and the Matlab error.jpg

P.S.2 The code seems to work fine on manufacturers system with Matlab 2011. so it may be Matlab-related, but I don`t get how since the error is from platdefines header file.

 

extcode.h

fundtypes.h

hosttype.h

ILVDataInterface.h

ILVTypeInterface.h

lv_epilog.h

lv_prolog.h

platdefines.h

STIM.aliases

STIM.dll

STIM.h

STIM.ini

STIM.lib

matlab error.JPG

Edited by farzane lk

Share this post


Link to post
Share on other sites

The DLL is 64 bit. Are you using 64 bit Matlab?

Share this post


Link to post
Share on other sites

If I had to guess, you'll want to edit STIM.h to include (at the very top, before anything else):

#define _Win64 1 //if 64 bit
#define _Win32 1 //any windows
#define _M_AMD64 100 
#define _M_X64 100 // same as above
#define __x86_64__ // and again, this might be the gcc version or something?
#define _MSC_VER 1900 // just a guess, this is ms visual c 2015

The full list of visual c #defines is here at this link, and you can also just go through the NI header file and look for stuff that makes sense.

https://docs.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=vs-2017

Edited by smithd

Share this post


Link to post
Share on other sites
19 hours ago, ShaunR said:

The DLL is 64 bit. Are you using 64 bit Matlab?

Yes, I`m using the 64bit version (2018a and 2015b)

Share this post


Link to post
Share on other sites
19 hours ago, smithd said:

If I had to guess, you'll want to edit STIM.h to include (at the very top, before anything else):

 

Thank you for the code. The good news is adding these 3 lines you gave me to the platdefine header`s list of "possible values" and editing the If, removed the former errors. YAY!!!

#define _Win64 1 //if 64 bit
#define __x86_64__ // and again, this might be the gcc version or something?
#define _MSC_VER 1900 // just a guess, this is ms visual c 2015

BUT Now I receive a bunch of errors (syntax). With the main error of  "Building STIM_thunk_pcwin64 failed." 😣

Googleing showed that the Matlab compiler is not properly making the "STIM_thunk_pcwin64.dll". There were solutions of changing the dll or the CPP file, which I`m too naive or too overloaded to understand now.
 

Thanks again

Share this post


Link to post
Share on other sites
8 hours ago, farzane lk said:

BUT Now I receive a bunch of errors (syntax). With the main error of  "Building STIM_thunk_pcwin64 failed." 😣

What is the first error? The exact message could provide valuable clues.

Given that the compiler wasn't auto-detected and that the same files work unmodified on the manufacturer system, I suspect that your compiler hasn't been set up properly.

Note: Visual Studio 2015 doesn't install the C/C++ compiler by default; you must explicitly select it during installation. Can you verify that you have a working C/C++ compiler on your PC?

Share this post


Link to post
Share on other sites

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
.....

 

Edited by smithd
  • Like 1

Share this post


Link to post
Share on other sites
On 2/4/2019 at 7:30 AM, JKSH said:

What is the first error? The exact message could provide valuable clues

Note: Visual Studio 2015 doesn't install the C/C++ compiler by default; you must explicitly select it during installation. Can you verify that you have a working C/C++ compiler on your PC?

 

Hi,

I attached the error I get.

and about the visual studio, yes I had reinstalled and selected the option. and it is selected in Matlab.

Screenshot (192).png

Share this post


Link to post
Share on other sites
On 2/4/2019 at 10:08 AM, smithd said:

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):

1

Hi again, sorry for the late reply.
Thanks for the guidance. 
I tried editing the STIM.h and the error didn`t disappear. it is still: "Error using loadlibrary" "Building STIM_thunk_pcwin64 failed."

but now the error refers to the "oncleanup" function, that is called for ending a function. 

I have attached the oncleanup.m and the error I`m getting. (its location was in matlab\toolbox\matlab\general\).
 

Seeing the error, it made me wonder if anything would change if I actually connect the device. (till now I was just trying to make the "loadlibrary" command work.)

2.png

1.png

onCleanup.m

Share this post


Link to post
Share on other sites

Your screenshots reveal the main problem: MATLAB is using an Perl script with regex to parse your header and generate its "thunk" code. Unfortunately, this script can't understand your header because it does not understand all C. (Your header uses "complicated" C)

It says, "Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30)". "Deprecated" means the functionality is old, and no longer encouraged. "Fatal" means the functionality is completely broken. And we can see that it is very broken indeed, because generated this line which is not valid C code:

EXPORT_EXTERN_C uint32_T(__cdecl__))OPEN_USB(voidThunk(void fcn(),const char *callstack,int stacksize)

 

It sounds to me like the Perl script worked fine on the older MATLAB 2011, but is broken by an incompatible upgrade in MATLAB 2018. I'd say that the fastest way to reach your goal is to downgrade MATLAB. (You might be able to get away with downgrading the copy of Perl that MATLAB uses, but I'm not sure if this is possible)

 

Side note: I also noticed that MATLAB is using GCC, not Visual Studio -- Look closely, and you'll see the compiler path: C:\TDM-GCC-64\bin\gcc. This means, even though you've told it to use Visual Studio, it's still using GCC.

Edited by JKSH

Share this post


Link to post
Share on other sites
5 hours ago, JKSH said:

Side note: I also noticed that MATLAB is using GCC, not Visual Studio -- Look closely, and you'll see the compiler path: C:\TDM-GCC-64\bin\gcc. This means, even though you've told it to use Visual Studio, it's still using GCC.

Yeah I looked again, I don't think matlab can use visual studio.

10 hours ago, farzane lk said:

Seeing the error, it made me wonder if anything would change if I actually connect the device. (till now I was just trying to make the "loadlibrary" command work.)

Nah this is a parsing problem.

 

Maybe I'm misreading the error but it looks like it doesn't know what __cdecl is -- __cdecl is visual studio specific. Since I think most compilers use that calling convention by default, you can safely remove all instances of __cdecl from stim.h

Share this post


Link to post
Share on other sites

Not directly related to dlls generated specifically by labview, but I happen to have also been dealing a lot with matlab loadlibrary on third part shared libraries during the last days, so I allow me the liberty of adding some comments. If that is not clear enough, let me stress: for loadlibrary to work, the matlab build chain has to generate this _thunk_ file, and it will succeed at it only if all is in place. Looking up "cannot build"  on the internet is bound to bring up irrelevant HELP ME  HELP ME posts; my winning strategy for importing was to start tackling the compilation errors from the first onward.

It should be clear that loadlibrary speaks only C, not C++. The perl parser does quite a good job on well written C headers, but does not handle everything (see, in matlab, help on "Limitations to Shared Library Support"); for one, it does not deal with unions and non typedef'd enums. The perl "deprecated unescaped left bracket" warning I got too, and for me it was merely a symptom, not the cause. When you've got .h files, check for anything which stinks of C++. If the .h file is really well written, it will have proper #defines which reduce the prototype syntax to something digestible by pure C. For example, defining EXPORT_EXTERN_C to be an empty string if not __cplusplus. If that is not, you may get through by pointing loadlibrary to your massaged version of the original header files. That is what I ended up doing in my current project, and fortunately involved only minor changes in them.

Matlab should be perfectly able to use visual studio afaik, but alas, there is a certain third party library which I managed to import rather easily in linux with gcc, whereas the corresponding windows version of it - well, I haven't even started to bugger about what VS wants from my life there (I might have to, soon... 😒)

Another strategy can be to interface with matlab by writing mex files. Mex files can be C++ (don't look at me I'm analphabet there).

Edited by ensegre

Share this post


Link to post
Share on other sites
18 hours ago, ensegre said:

Matlab should be perfectly able to use visual studio afaik, but alas, there is a certain third party library which I managed to import rather easily in linux with gcc, whereas the corresponding windows version of it - well, I haven't even started to bugger about what VS wants from my life there (I might have to, soon... 😒)

Ah yeah I read a note that said a specific visual studio version was no longer supported, should have scrolled down further.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

By using this site, you agree to our Terms of Use.