LabVIEW
Error 1498
If you choose to NOT include them in your executable build, we have found that the only way to not have to start to hack into the App Builder, Project Provider Framework and what else, is to currently build the lvlibp's to a fixed absolute path such as C:\<your project>\.... and reference them from there for your development of other packed libraries and executables and distribute them like that together with build applications.
Anything else except always including all packed libraries always in your executables will grow you gray hair up to and including in LabVIEW 2020 SP1. It even fails if you try to install packed libraries in any of the vi.lib, user.lib, instr.lib paths just for development, as soon as they reach 3 or more dependency levels and especially when packaging classes in them. My suspicion is that LabVIEW runs into a fundamental dependency loading problem, where it tries to load classes from the top to the bottom but packed libraries need to be loaded from the bottom up if they reference VIs that are located in so called pseudo paths, which vi.lib, instr.lib, and user.lib are. For these paths LabVIEW stores the path reference as a special path in the VI that is called a pseudo path. The idea is good, in that LabVIEW will always attempt to load these paths from it's own private copy of these directories rather than attempt to load them from <Program Files>\National Instruments\LabVIEW 20XX because it was last compiled in LabVIEW 20XX instead of LabVIEW 20YY that currently tries to load them.
But this pseudo path resolution only seems to happen when the VIs are loaded with the search dialog enabled, which the Application Builder and Project Provider framework specifically try to avoid to not bother the user with umptien such dialogs when trying to load a broken project.
@CoastalMaineBird wrote:
I think my particular problem is something else, though. It turned into a LV crash some time ago. But the thing is, loading PPL B does NOT crash if I load PPL A first. It also does NOT crash if I disable the calls in PPL B that call VIMs (malleable). Everything loads fine and works (except for the missing functionality of the VIMs of course).
Well I remember something about VIMs in packed libraries being yet another beast that hasn't been really tamed yet. It's also not quite the original intended use case I guess, since VIMs are clearly meant for development libraries and packed libraries are hardly that. I would expect them however to work for building libraries that somehow might be USING VIMs, but yes providing VIMs inside packed libraries for use elsewhere is not likely ever a supported use case.
