Conditional disable structure for shared library calls 32 and 64 bit

[D. Ackermann]

Hi

I am looking for an efficient solution to create a VI library for LV 32 and 64bit, that uses a dll. I spent about a day now without success..

I am cretating the library with LV 2019 and saving it for LV 2013 to have it available for older LV versions. The dll has the same name in 32 and 64 bit version.

I am using the conditional disable structure to detect if it is LV 32 or 64 bit in the code. In the structure are 2 call library function nodes. One for 32 and 64 bit version of the dll. The dll is in a subfolder of the VIs. The VIs are organized in a lvlib. I also added the dll to the lvlib. So all the information is there..

- First I configure the call library function node in LV 32 bit.
- Then I save all and close LV.
- Replace the dll in the folder with the 64 bit version.
- Then open LV 64 bit and configure the second CLFN
- Save all
- Then save the whole LV project for LV 2013.
- Then change the path to my current LV project. Otherwise LV 2013 would just use dll from my LV2019 project.
- Go to the location of the LV 2013 project. Raplace the dll with the 32 bit version
- Then open LV 2013 project in LV 32 bit.
- Open a VI that calls the dll and get the search dialog saying it cannot find the dll
- When looking into the CLFN, I see the the absolute path to the dll in my LV 2019 project is saved in the path field.

I tried using a relative path in the CLFN path field, but it always replaces it with the absolute path. Just setting the dll name is not an option, because I need that the dll is automatically put in the data folder when building an exe.

I think the problem is, that the CLFN nodes are messing with the information put into the path field. If I could enter a relative path, that is not replaced with an absolute path it should work.

Did anybody go through the same pain here? I really want to avoid having two VI sets for the library for 32 and 64 bit.

Thanks

 

 

 

 

 

 

 

[dadreamer]

39 minutes ago, D. Ackermann said:

I tried using a relative path in the CLFN path field, but it always replaces it with the absolute path.

From my own experience with CLFNs, if you set "Specify path on diagram" checkbox in the CLFN's settings, LabVIEW always uses the path from the diagram and never uses the path from "Library name or path" field. When you set that checkbox everywhere, all you need is to construct proper path for both 32 and 64 bits and pass it into your CLFN(s). Here's the article, which may help: How to Configure LabVIEW to Use Relative Paths for DLLs?

Another option for you might be using of an asterisk in the library name to distinguish between 32 and 64 bits. Refer to Configuring the Call Library Function Node article and look for how to use the * wildcard.

Edited July 15, 2020 by dadreamer

[ensegre]

as dadreamer says. One place where I remember I have used it is https://gitlab.com/enricosegre/LVVideo4Linux . Look in LV-libv4l2/Ancillary/libv4l2_path.vi and all its callers for an example.

[D. Ackermann]

Yes, I thought about both options before. Both don't really work for me.

If I use "Specify path on diagram" checkbox, the dll is not automatically put in the data folder when building an exe.

And it is actually not one dll. It is multiple dlls from another company. The dlls have linkage between them. So I cannot change the naming.

 

Thanks.

[ensegre]

can't you put the 32 and the 64 set in two different directories and use the path-from-diagram?

[D. Ackermann]

Ok, I just found out, that if I add an additional step of pointing the CLFN to the dll again in LV 2013 and saving the project. Opening the project in LV 2019 from a different location works for LV 32 and 64 bit.

So I guess the problem is somehow conencted to saving the project for previous version.

I can live with this..

 

[dadreamer]

30 minutes ago, D. Ackermann said:

If I use "Specify path on diagram" checkbox, the dll is not automatically put in the data folder when building an exe.

All the DLLs may be added into the project manually (by RMB click -> Add -> File) and in the build spec's on the Source Files tab the DLLs should be put into Always Included category. When the build finishes, you will have the DLLs in the 'data' folder. Just tested with a trivial project and it worked fine.

[drjdpowell]

I just add my dlls to the LVClass that uses them, with the path to 32 or 64-bit dll generated in a Condition Disable.  The EXE's then include both dlls automatically.  See SQLite Library as an example.