LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

What compiler is used when building a LabVIEW dll ?

Solved!
Go to solution

We have provided our customer with a DLL built with LV2019, which is further integrated in a third-party simulation software.

Since the dll import is not working on their machine, our customer is asking us information about the compiler used.

 

Problem: we have no idea because it is internal to LabVIEW and no option in the build specification allows to select a specific compiler...

 

So I am looking for the following information:

 

1. What compiler is used by LabVIEW to build a DLL ?

Is it a standard one or one specific to LV ?

If standard, how to know the version of the compiler ?

 

2. What about the bitness compatibility between the LabVIEW used to build the DLL, the application that imports the DLL and the machine (Windows 10) that runs the application ?

For example, is a DLL built with a 32bit LabVIEW compatible with a 64bit application ?

 

3. What about portability ? Is the DLL usable by other platforms than Windows ?

 

Thanks.

0 Kudos
Message 1 of 4
(1,434 Views)
Solution
Accepted by topic author raphschru

@raphschru wrote:

We have provided our customer with a DLL built with LV2019, which is further integrated in a third-party simulation software.

Since the dll import is not working on their machine, our customer is asking us information about the compiler used.

 

Problem: we have no idea because it is internal to LabVIEW and no option in the build specification allows to select a specific compiler...


It's probably the wrong question.

 

I don't see any relevance...

 


@raphschru wrote:

So I am looking for the following information:

 

1. What compiler is used by LabVIEW to build a DLL ?

Is it a standard one or one specific to LV ?

If standard, how to know the version of the compiler ?


LabVIEW uses the LLVM compiler.

 

It's probably specific to LV, in that there might be some tweaks to work better with LabVIEW.

 

I'm not sure how to find out the version.

 

Again, AFAIK, it should make any difference. 

 


@raphschru wrote:

2. What about the bitness compatibility between the LabVIEW used to build the DLL, the application that imports the DLL and the machine (Windows 10) that runs the application ?

For example, is a DLL built with a 32bit LabVIEW compatible with a 64bit application ?


The dll is the same bitness as the LabVIEW version used to create it.

 

The OS bitness is not relevant, but 32 bit LabVIEW can run on 64 bit windows. 64 bit LabVIEW can't run on 32 bit Windows (if you can find a 32 bit windows in the first place).

 

The calling application needs to match the bitness of the dll. 32 bit process cannot call 64 bit dlls and vice versa.

 

 


@raphschru wrote:

3. What about portability ? Is the DLL usable by other platforms than Windows ?


No.

 

You need a Linux DLL (.a or was it .o?) for Linux, a .dll for windows. Both need the correct bitness for the calling application.

 

A LabVIEW DLL does need the (correct) LabVIEW runtime engine!!!

 

Without the correct LabVIEW runtime engine, no LabVIEW exe or dll will run.

 

Note that newer RTEs should run older dlls (e.g. LV22 RTE will run a LV20 dll) if it's enabled in the build specification. Again, the bitness of the RTE needs to be correct.

 

You can either download the runtime engine, or make an installer for an exe that includes the RTE. 

Message 2 of 4
(1,425 Views)

Linux shared libraries (which is the platform independent name for DLLs) have an .so extension, need to be in ELF format and compiled for the CPU on which it is intended to use (however LabVIEW only is available in Intel 64-bit since version 2017 so no Linux 32-bit builds are possible anymore, and before 2014 it was only 32-bit).

Mac shared libraries have either a .dylib extension (when being a Mach-O object file format) or with the .framework extension (when being a bundle that can contain multiple CPU architectures). Here the same applies, before 2014 it was only 32-bit Intel, and since 2017 it is only 64-bit Intel, and in a future version it will likely be Apple ARM 64-bit.

Windows DLLs can come in either 32-bit or 64-bit versions, need to be in the COFF PE file format, and only can be created with the according LabVIEW version and only loaded by an application with the same bitness. It's likely that LabVIEW in a not to distant future version will be 64-bit only (also on Windows) on all platforms except the ARM RIO targets.

Rolf Kalbermatter
My Blog
Message 3 of 4
(1,376 Views)

wiebe@CARYA  a écrit :

The calling application needs to match the bitness of the dll. 32 bit process cannot call 64 bit dlls and vice versa.


Thanks, I was never sure about that...

I also found the NI article explaining exactly what you said: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000PA7SSAW&l=fr-FR

 

Since our customer's application is 64bit, I recompiled the dll with LabVIEW 64bit and it worked !!

Message 4 of 4
(1,276 Views)