CLFN - linking with 32bit/64bit dll with same name

[L2L]

Got bit of a problem, the call library function node and LabVIEW can switch between 32-64 dlls by using "*" in the file name when specifying a path. This is fine for a dll that I build.. where I can add '32' or '64' to the name to differentiate between the two, but I also use the lua52.dll that has the same name for both 32bit and 64bit versions.

Now if only I could use the "*" in the CLFN to automaticly choose the correct directory which I could name '32\lua52.dll' or '64\lua52.dll' other than that.. I could specify the path from the block diagram, but then I loose automatic dependency detection.

[ShaunR]

Is there any reason you cannot use the TARGET_BITNESS of a conditional disable structure?

[L2L]

Wow, didn't know you could do something like that. I'll quickly go check if its going to work

[L2L]

Nope... LabVIEW still wants to load the 64bit dll - even in the conditional disable structure, with a TARGET_BITNESS of 64

it then complains it can't find the function/library

Edited September 12, 2012 by L2L

[L2L]

looks like you can do it, but you have to make the path changes without the 64bit version of the dll in the directory you specify in the CLFN - because if it is there LabVIEW will try and load it while your inside the CLFN configuration utility, and then it updates both of your CLFNs paths in the conditional disable structure to point to a single dll

[Rolf Kalbermatter]

looks like you can do it, but you have to make the path changes without the 64bit version of the dll in the directory you specify in the CLFN - because if it is there LabVIEW will try and load it while your inside the CLFN configuration utility, and then it updates both of your CLFNs paths in the conditional disable structure to point to a single dll

The proper solution is to use some kind of installation tool like VIPM and install either DLL, depending on the bitsize of the installation target into the same directory. Ohh wait VIPM doesn't support file specific version settings, when building a package! Well the good old OpenG Package Builder does! And its opg file format is still used and recognized by VIPM too. If you want to stay with VIPM you have to use the PostInstall step to make those modifications after the installation.

Your proposed solution has at most some hackish merits. It will cause many problems further down the road as you will edit the VIs and forget sometimes to follow the very strict VI open protocol to avoid it. And even if you won't others using your library for sure will.

[L2L]

The proper solution is to use some kind of installation tool like VIPM and install either DLL,

I've looked a bit closer and the hack I described does not work. Will follow your great idea of a post install step - thanks

[Mr Mike]

What do you mean by linking? Do you just mean be able to use the DLL? You can wire in a path, but that will cause the connection (or "link" if you will) to the dll to not be made, so you'll need to remember to include the DLL every time you package up the files (or rather, anything that traverses the dependencies of a project).

[Rolf Kalbermatter]

What do you mean by linking? Do you just mean be able to use the DLL? You can wire in a path, but that will cause the connection (or "link" if you will) to the dll to not be made, so you'll need to remember to include the DLL every time you package up the files (or rather, anything that traverses the dependencies of a project).

That's what he seems to point at here:

Now if only I could use the "*" in the CLFN to automaticly choose the correct directory which I could name '32\lua52.dll' or '64\lua52.dll' other than that.. I could specify the path from the block diagram, but then I loose automatic dependency detection.

And it indeed adds an extra hassle to building an application with such a library. But I don't think the solution is in allowing even more wild card options to also specify relative path patterns. A 64 Bit DLL simply shouldn't be installed on a 32 Bit app installation and vice versa. If VIPM would support specifying platform settings for individual files or file groups, that would be quite a moot point, I think. I solved it for me by creating my own improved version of the OpenG Package Builder, which supports that option.

(The improvements were not to support this, it already does! But its user interface and some other options are a bit limited. Also note that VIPM does provide quite a different UI for defining a package. More user friendly but harder to add the feature to specify platforms and versions for individual files)

[MikaelH]

I've solved exactly this problem with the "TARGET_BITNESS of a conditional disable structure".

I just open the same VI with LV 32 and 64 bit version to configure the dll path.

I always create 2 folders "32" and "64", where I have the dll's with the same name.

//Mike

[Mr Mike]

That's what he seems to point at here:

...and that's why I shouldn't try to help people first thing in the morning.

[Rolf Kalbermatter]

I've solved exactly this problem with the "TARGET_BITNESS of a conditional disable structure".

I just open the same VI with LV 32 and 64 bit version to configure the dll path.

I always create 2 folders "32" and "64", where I have the dll's with the same name.

//Mike

I think you might still end up with interlinking problems at least in some versions of LabVIEW. I know that LabVIEW will revisit ALL CLNs loaded into memory linking to a specific DLL name if you change one CLN to load this DLL name from a different location. It should of course completely ignore anything inside a conditional disable structure, but I'm sure it didn't in some versions.

Also with simply installing the right DLL for the platform you can avoid the conditional disable structure AND also develop on only one platform without the need to load the VIs on both platforms and make edits. Of course you have to test it on the other platform too, but you don't have to load each VI in every different platform everytime you change something on the CLN.

[MikaelH]

I think you might still end up with interlinking problems at least in some versions of LabVIEW.

It works fine for me in LV2010, I just build my exe file in LV2010-32 bit, then I open the same project in 2010-64 and builds it again without any problems. Maybe I've just been lucky :-)