Building of packages with shared libraries with wildcard name in the Call Library Node produces wrong VIs

[RolfKal]

Short Description of the Bug (in one or two sentences)

When building a VI package that contains Call Library Nodes calling shared libraries, and the Call Library Node using wildcard names to allow for bitness and platform patterns in the library name, the resulting VIs are compiled with the resolved shared library name for the current platform and bitness, loosing the ability to create platform and bitness agnostic VI libraries when they call shared libraries.

Version Information

VIPM Version and Build:
2013, 2020.3

Operating System Version:
Windows 7. Windows 10, Windows 11

LabVIEW Version:
LV2009, LV2013 SP1, LV2017 SP1, 2020 SP1 and so on.

LabVIEW Bitness:
32-bit and 64-bit LabVIEW

Virtualization or Processor Version Information
VmWare and native

Steps To Reproduce
Build a VI with a Call Library Node that calls a 32.dll or 64.dll shared library depending on the platform.
Enter in the Library Name in the Call Library Node "dllname*.*".
Test that it calls the according DLL depending if you run LabVIEW 32-bit or LabVIEW 64-bit.
Build a VI package, and install it both into a LabVIEW 32-bit and LabVIEW 64-bit installation. The VI will load broken on the other platform than it was built on.

Expected behavior
Leave the wildcards in the Library Name intact.

Actual Behavior
This is because the package builder relocates and resaves the VIs before building the package and that will resave the VIs with a new Library Name that has the * wildcards replaced with the actual values for the platform on which it was built. Resulting in the Call Library Node trying to reference the wrong DLL on the other platform.

Anything else you'd like us to know?
Relevant thread on LavaG: https://lavag.org/topic/23809-openg-labview-zip-500-1-stuck-at-the-readme

[Tom-McQuillan]

This doesn't resolve the issue, but I'm commenting this workaround for others who find themselves here:
Developers often explicitly specify DLL paths (typically inside a conditional disable structure) when they are building the API into a VIP or EXE.