Jump to content

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


L2L

Recommended Posts

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.

Link to comment

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

Link to comment

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.

Link to comment

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

Link to comment

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)

Link to comment

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.

Link to comment

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

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

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