Rolf Kalbermatter
-
Posts
9 -
Joined
-
Last visited
-
Days Won
1
Posts posted by Rolf Kalbermatter
-
-
On 4/12/2024 at 6:28 PM, Thomas ALLIBE said:
So, for LV24 64bits, I did a manual mass compile of "C:\Program Files\National Instruments\LabVIEW 2024\user.lib\_OpenG.lib\lvzip" and got these logs and now the lib is working.
But if I change version or re-install the package I need to mass compile it again... I wonder why it's not working with the first mass compile done by VIPM.
For LV20 32bits it does nothing: no log, no error and same DLL path issue...
Hmm, I assume you also use VIPM 2024 or whatever is shipped with LabVIEW 2024? I haven't tried to install with that yet, but it would seem there is some sort of regression here. Someone obviously is relinking the DLL path to "<userlib>:\source\lvzlib.dll" and that was not me when building the package which actually is referencing my own build path on my virtual machine at "Z:\openg-lvzip\openg-lvzip\source\lvzlib.*". Unfortunately it seems almost impossible to change that path to something more correct during package build.
Did you make sure to install 5.0.2.0? This should solve several possible problems during install. 5.0.1.0 should not be used as there were indeed some installation and linking problems in the package build.
-
The package is supposed to request a mass compile after installation which should fix this issue. However that second path in LabVIEW 2020 looks very weird. Seems that VIPM is somehow relinking those paths but not in a good way.
I just did a test install on LabVIEW 2020 SP1 f1 32-bit and there is nothing like that present. I see that VIPM properly does initiate a mass compile after installation and when afterwards looking at the VI's the past for the DLL is correctly pointing at where the DLL is supposed to be with a (star as ending instead of dll, but that is the correct and intended way).
-
I uploaded a new version 5.0.1.0-1 which should address this and installation issues on Linux.
-
1
-
-
I uploaded a new version 5.0.1.0-1 which should address this installation issues on Linux.
-
I uploaded a new version 5.0.1.0-1 which should address this and installation issues on Linux.
-
I uploaded a new version 5.0.1.0-1 which should address this and some other installation issues for Linux.
-
The font looks somewhat different to what I’m used. I’m this week out of the office and have no access to a computer but will look into it next week.
-
2 hours ago, Jim Kring said:
@Zaphiro Technologies
CC: @RolfK
There is a cross-platform shared library naming trick. (It could be that the package build process messed up the paths when writing linker info.)
See: LabVIEW Help >> Configuring the Call Library Function NodeYes, I had until recently always build everything in LabVIEW 7.0 and had apparently in a long ago past patched the OpenG DEAB functions to not bork those shared library names (as I carefully made sure to use this trick in the source code version in every single VI). But because of a complete reinstallation of my Linux Virtual Machines I also had to move to a LabVIEW 8.6 installation for testing, I had preferred 2009 but could not find a Linux installer for that, and I had completely missed that the default OpenG DEAB seems to rewrite the linker information with fully explicit shared library name.
-
1
-
Archive not password protected
in OpenG LabVIEW ZIP Library by OpenG
Posted · Edited by Rolf Kalbermatter
That are not two separate issues but the second is the sole reason for the first. Apparently the Bundle By Name node somewhere adapted to the wrong item, probably when editing the cluster typedef at some point. And I missed that!
Simply changing that to the password item should fix the problem.
Thanks for the report, I'll be looking into that soon.