unzip.vi fails to unzip lvappimg

[Antoine Chalons]

On Windows I use the NI_Unzip.lvlib:Unzip.vi to unzip normal zip files as well as lvappimg file (cRIO image file created by MAX or RAD) and it works.

On Linux NI_Unzip.lvlib:Unzip.vi can unzip normal zip files but always return error 42 when I try to unzip a lvappimg file.

I've reported this as a bug to NI

 

Anyone knows another way to unzip a lvappimg file?

cross-posted to NI Forums

Edited September 3 by Antoine Chalons
crosspost link

[Rolf Kalbermatter]

1 hour ago, Antoine Chalons said:

On Windows I use the NI_Unzip.lvlib:Unzip.vi to unzip normal zip files as well as lvappimg file (cRIO image file created by MAX or RAD) and it works.

On Linux NI_Unzip.lvlib:Unzip.vi can unzip normal zip files but always return error 42 when I try to unzip a lvappimg file.

I've reported this as a bug to NI

 

Anyone knows another way to unzip a lvappimg file?

cross-posted to NI Forums

Did you try with OpenG ZIP library?

https://www.vipm.io/package/oglib_lvzip/

No guarantee that it works as I never considered testing that, but it is a quick test.

Edited September 3 by Rolf Kalbermatter

[Antoine Chalons]

i sure will

It does look like the unzip.vi is using a CLFN that calls functions of the LabVIEW app so it might be doing some special stuff.

[Rolf Kalbermatter]

On 9/3/2024 at 7:42 PM, Antoine Chalons said:

i sure will

It does look like the unzip.vi is using a CLFN that calls functions of the LabVIEW app so it might be doing some special stuff.

It could, but generally, the unzip functions in the LabVIEW runtime are simply a (somewhat older) version of the ZLIB code plus MiniZIP, the same I'm using in OpenG ZIP. Of course OpenG ZIP 5.0 has been updated to use the latest ZLIB sources, an alternate extended version of MiniZIP that supports 64-bit ZIP files and ZIP streams, and Unicode file name support.

Since ZLIP and MiniZIP in the contributed part of ZLIB are under the extremely liberal ZLIB license, similar to the 3 clause BSD license, NI is free to include it directly in the LabVIEW runtime.

Edited September 4 by Rolf Kalbermatter

[Antoine Chalons]

VIPM 2022 keeps giving an error when trying to install version 5.0.0

I could install 4.0.0 but it seems the so file is not installed by VIPM

more recent version seem to not be supported on Linux (at least they are disable in the VIPM ring menu)

So I installed 4.2.0b1-1 found on LAVA and now I can test : no luck on Linux

Edited September 3 by Antoine Chalons

[Antoine Chalons]

oh, and with 4.2.0b1-1 on Windows, it works, it can successfully unzip an lvappimg.

 

Edited September 4 by Antoine Chalons

[Rolf Kalbermatter]

8 hours ago, Antoine Chalons said:

oh, and with 4.2.0b1-1 on Windows, it works, it can successfully unzip an lvappimg.

I’m intrigued. Linux support for > 5.0.0 is definitely in the package, why it doesn’t allow you to select it is not yet clear to me.

I have a hunch why it might not work in pre 5.0 version but that that doesn’t affect the Windows version is strange. How large is the lvapp image?

Edited September 4 by Rolf Kalbermatter

[Antoine Chalons]

in 4.0.0 the CLFN had an absolute path to the shared lib that was like /C/Work/OpenG/....
and I couldn't find the actual so file under ~/user.lib and didn't feel like relinking all the CLFNs anyway as I knew that 4.2 would work.

 

The size of the lvappimage I tested with is ~360 MB

[Rolf Kalbermatter]

49 minutes ago, Antoine Chalons said:

in 4.0.0 the CLFN had an absolute path to the shared lib that was like /C/Work/OpenG/....
and I couldn't find the actual so file under ~/user.lib and didn't feel like relinking all the CLFNs anyway as I knew that 4.2 would work.

The size of the lvappimage I tested with is ~360 MB

Well, you should definitely try 5.0.3, 5.0.0 to 5.0.2 had various problems in terms of proper installation on specific platforms and the shared library path having been messed up by the build tools in the sources for the package.

[Antoine Chalons]

VIPM still blocks 5.0.3

If I try to install it from the menu (File >> Open Package File(s)) I get error 5000

[Rolf Kalbermatter]

I will try this evening at home to see why that is. It SHOULD actually work but the whole building of the package has turned out to be a lot more hassle than I remember having had in the past.

[Antoine Chalons]

if I can help in any way with testing on Linux, DM me.

[Rolf Kalbermatter]

23 hours ago, Antoine Chalons said:

if I can help in any way with testing on Linux, DM me.

I need a bit more info here!

First: versions before 4.2 had no support for 64-bit, neither Windows nor Linux. Unless you use LabVIEW 2016 or earlier, your LabVIEW for Linux version is 64-bit. Since you can use 4.0.0 in Windows, I have to assume that you use the 32-bit version of LabVIEW there.

Is there a chance that you could try it with 64-bit LabVIEW under Windows with the >= 5.0.0 version of OpenG ZIP Library?

 

Second: it seems VIPM treats Windows differently to Linux as allowed target indicator:

Windows NT: means all NT derived Windows versions indpendent of bitness

Windows x86: is only Windows 32-bit

Windows x64: is only Windows 64-bit

Linux: is only Linux 32-bit

Linux x64: is 64-bit Linux

 

I tried to verify some of the packages on VIPM.io and if they want to explicitly say that they are for Linux, they seem to all only specify "Linux" as allowed target. Yet according to your results such packages couldn't install on LabVIEW 2017 and newer on Linux!

Could you try for a quick laugh if you can install one of the following packages on your Linux system?

- labview-zmq-3.6.2.112

- denso_robotics_lib_dpam_robot_library-2.1.0.75

- electric_power_research_institute_lib_opendss_library_x64-1.0.0.7

- national_synchrotron_radiation_laboratory_lib_nsrl_cas_interface_linux-1.0.0.5

- ogrsc_restart-1.3-1

- ovak_technologies_lib_labview_universal_xml_parser-1.0.0.13

- pantherlab_lib_panther_dashboard-x.x.x.x

- sas_workshops_lib_clearlvcache_for_g_cli-1.0.x.x

- sas_workshops_lib_clearlvcache_for_g_cli-1.0.x.x

Edited September 5 by Rolf Kalbermatter

[Antoine Chalons]

Indeed, on Linux (Ubuntu 20 and 22) wuse use LabVIEW 2021 (therefore 64-bit)

And on Windows 10, we use LabVIEW 2021 32-bit, about 5 years ago we made that choice because of some toolkit that was 32-bit only, but now we only deploy our LabVIEW built apps NI Linux RT or in Ubuntu containers.

I don't have LabVIEW 64-bit installed on any Windows, one of my colleagues might, I'll ask around tomorrow.

 

one thing I didn't mention is that I was using VIPM 2022.1 on Linux

I've tried with VIPM 2017, here it looks more "friendly" :

but when trying to install 5.0.3 I get an error :

 

I do use zeromq Library on Linux, installed with VIPM 2017

And I've just installed opendss 1.0.0.7 semi-successfully with both VIPM 2017 and 2022 (on 2 different Ubuntu VMs).

I say semi-successfully because in both cases the multicore analysis and sparse matrix dependency failed to install with error 5000

[Antoine Chalons]

and VIPM 2022 fails to install zeromq with error 5000, while VIPM 2017 could install it.

[Rolf Kalbermatter]

Seems VIPM 2022 got picky about interpreting Linux as a valid platform indication for anything but 32-bit LabVIEW for Linux? That would be in fact a bug.

Error 8 is a permission error. In that Post Install VI I try to clear the write protection on the 32-bit shared library file to be able to delete it so I can copy the 64-bit DLL over it. Does the user under which you are logged in and run VIPM have admin privileges?

I guess there is no (easy) way to see the permissions of the lvzlib.so right before that Post Install VI executes.

Does the zero-mqtt toolkit also show as disabled in the VIPM 2022 version?

Edited September 6 by Rolf Kalbermatter

[Antoine Chalons]

8 hours ago, Rolf Kalbermatter said:

Seems VIPM 2022 got picky about interpreting Linux as a valid platform indication for anything but 32-bit LabVIEW for Linux? That would be in fact a bug.

Does the zero-mqtt toolkit also show as disabled in the VIPM 2022 version?

Indeed, in VIPM 2022.1 zeromq doesn't even show in the list as the default config is "only show installable packages"

If I disable this, I see zeromq in the package list but can't install. Clearly a bug.

On the VIPM discord Jim said that a lot of work is being done to release a new VIPM for Linux "soon" so I'll make sure to bring this to his attention.

 

8 hours ago, Rolf Kalbermatter said:

Error 8 is a permission error. In that Post Install VI I try to clear the write protection on the 32-bit shared library file to be able to delete it so I can copy the 64-bit DLL over it. Does the user under which you are logged in and run VIPM have admin privileges?

I guess there is no (easy) way to see the permissions of the lvzlip.so right before that Post Install VI executes.

99% of my issues on Linux are privileges issues.

- on the VM with VIPM 2017, i need sudo to launch VIPM and after installing a package I always run a `chown user:user` on the installed package ; surely there is a way to fix this but I got used to it.

- on my Linux runner VM (for CI) it's the same, VIPM 2017 with sudo needed, as I rarely change the packages, it's a tolerable pain.

- on the other VM with VIPM 2022.1 I don't need sudo.

Actually for zeromq, we have modified the package and rebuilt it, online version 3.6.2 is "Linux and Windows", the one we built is "all OS"

so that's a work-around for the bug in VIPM 2022.1, set "all OS" and then you can install on Linux.

Edited September 6 by Antoine Chalons
typo

[Rolf Kalbermatter]

Thanks, that makes a lot of sense. Unfortunately the 32/64-bit support in VIPM was for a long time more or less non-existent, just as my 64-bit version of OpenG ZIP. 😁

When it was added, ca. 2015/2016 or so, it was a quick and dirty fix but not a thorough design (design here doesn't mean it's a mega project, but that there would have been some deliberate choices and decisions). And later fixes seem to have made things rather worse than better. 😏Not that I'm complaining. Multiplatform support for a tool like VIPM or OpenG ZIP is a major pain in the ass! Especially the testing!

That permission issue seems to get a bummer! It looks to me as if the installation of the files to the LabVIEW directory is done in the context of VIPM, so the files inherit root ownership when run in VIPM 2017. Then the Post-Install hook is executed in the context of the LabVIEW installation through VI Server and that operates of course non-elevated and has therefore no rights to change the file attributes or delete the file afterwards. And the platform specific indication in the package to only install specific files depending on the target bitness is not present (pre VIPM 2016), not 32-bit specific (VIPM 2016,2017) or to specific (VIPM 2022 and maybe prior).

Having to select "Linux x64" for LabVIEW target bitness is anyhow not really correct, although understandable since the underlaying VI Server property in LabVIEW distinguishes the bitness of LabVIEW by modifying the according "App.TargetOS" property. And that was how we had implemented these package properties in OpenG Builder back in a far ago time. When adding 64-bit support to VIPM I would rather have seen them to extend the LabVIEW version property to {LabVIEW, LabVIEW 32Bit, LabVIEW 64Bit}, or something like that (technically LabVIEW x68 and LabVIEW x64 would have worked too, since the Intel platform was the only one that allowed for bitness differences in LabVIEW. But of course if you think that far already why limit it on such a thing that could have changed theoretically in the future and did with the addition of Apple Silicon Support which is not x64 but MacOS ARM64). Strictly speaking LabVIEW should only use Linux x64 (or Windows x64), if it runs on a 64-bit kernel and otherwise just Linux (or Windows NT). All those little pesky, hard to imagine, future developments!!

Will have to think a bit about this, but it's going to be tough to allow for installation in both VIPM 2017 and VIPM 2022 with the same package I'm afraid!

 

 

Edited September 6 by Rolf Kalbermatter

[Antoine Chalons]

I see that it's not trivial to handle properly all the cases, to avoid error 8 when installing the zip package the first time, my suggestion is to edit the post install vi like I did below, quick and dirty, works for me

[Rolf Kalbermatter]

58 minutes ago, Antoine Chalons said:

I see that it's not trivial to handle properly all the cases, to avoid error 8 when installing the zip package the first time, my suggestion is to edit the post install vi like I did below, quick and dirty, works for me

I appreciate your cooperation but there are a number of difficulties with this!

1) I try to avoid dependencies in the package including the Script VIs in OpenG ZIP Library > 5.0. It's not strictly necessary as the dependencies should be already installed at the time VIPM gets to install the real package, but I had situations where this was adding an additional problem.

2) More seriously though, it's not the fact that trying to delete it might fail if the file isn't there. That I wouldn't care and could also ignore by simply adding a Clear Error.vi after the Delete. But even with this change of yours the Delete function will still fail either by trying to clear the write protection on the file it has no access too or if I skip that by trying to delete the file it has no access to. Even ignoring that error won't help as the Move consequently will fail then too.

For VIPM 2022 ignoring any error from the Delete should however work, as it copied the files from the archive to the target location with the same user rights as what LabVIEW was started up with.

For VIPM 2017 there is unfortunately no way to avoid having the 32-bit so installed. If I mark it as Linux only it will install in both cases.

But!!!!! I just noticed that the <library name>*.* wildcard naming in the Library Name control for the Call Library Node seems to work even in LabVIEW 8.6 (which had no 64-bit release). This saves the day!! I just can install the shared library with the 32 and 64 bit postfix alongside each other and be done, without having to abandon support for 8.6!!

Thanks Brian Powell! 

Edited September 6 by Rolf Kalbermatter

[ShaunR]

39 minutes ago, Rolf Kalbermatter said:

I just can install the shared library with the 32 and 64 bit postfix alongside each other and be done, without having to abandon support for 8.6!!

Installing both binaries huh? Don't blame you. It takes me forever to get VIPM to not include a binary dependency so I can place the correct bitness at install time with the Post Install (64bit and 32bit have the same name. lol)

[Rolf Kalbermatter]

31 minutes ago, ShaunR said:

Installing both binaries huh? Don't blame you. It takes me forever to get VIPM to not include a binary dependency so I can place the correct bitness at install time with the Post Install (64bit and 32bit have the same name. lol)

VIPM has limited and varying support for that depending on its version. "Linux" in VIPM 2017 means any LabVIEW version for Linux. "Linux x64" is not a thing before VIPM 2016 or so, but means 64-bit in VIPM 2017 and newer. And "Linux" in VIPM 2022 means 32-bit LabVIEW only, which is pretty stupid considering that LabVIEW for Linux is 64-bit only since 2017. Definitely an oversight by the VIPM developers that should be fixed. You don't want to require to have to explicitly specify "Linux x64" as supported target for packages that don't even have binary dependencies inside.

It's doable with a Post Install VI in the package that renames the shared libraries after installation, except with VIPM 2017 and maybe others, which needs to run with root privileges to do anything useful.

As my main Linux test system is still LabVIEW 8.6, newer versions have various troubles for me from inability to get a full installer for them to installation trouble on my Linux VMs, I did not want to abandon this version but was under the wrong assumption that it would not support the wildcard library naming to distinguish between 32-bit and 64-bit files, since the first version of LabVIEW supporting 64-bit was 2009. Obviously Brian had been starting to work on 64-bit support earlier already and not all of that support was removed by some precompile symbols it seems, so it is already present in 8.6 LabVIEW. Most likely it would have been possible to release LabVIEW 8.6 for 64-bit but probably with some bugs here and there.

Of course VIPM Package Builder doesn't really support setting specific platform and bitness limitations on individual files or file groups, only on the full package. But I'm using my own OpenG Package Builder instead which has all those possibilities, yet it doesn't really help if VIPM then goes and messes that up anyhow. But creating my own package manager is definitely one step to far for my mental health. 😁

[Rolf Kalbermatter]

On 9/3/2024 at 5:28 PM, Antoine Chalons said:

On Linux NI_Unzip.lvlib:Unzip.vi can unzip normal zip files but always return error 42 when I try to unzip a lvappimg file.

Next step is trying to find out how OpenG ZIP Library fails on the lvappimg. My suspicion still is that it is an issue with the fact that the library is compiled for 64-bit. So am going to test it with 64-bit on Windows. Except that I'm using of course the most recent version 5.0 of the library which had quite a bit of changes in the C code to support 64-bit archives. So there is a very good chance that it simply will work.

I can provide you with a prerelase of 5.0.4 that should install under Linux with both VIPM 2017 and 2022 if that helps. That would show if it is still a problem in the current code base. As it is I have not a working 64-bit version of LabVIEW for Linux at this point.

[Antoine Chalons]

that would be great, if you send me 5.0.4 i can install and try

[ShaunR]

4 hours ago, Rolf Kalbermatter said:

It's doable with a Post Install VI in the package that renames the shared libraries after installation, except with VIPM 2017 and maybe others, which needs to run with root privileges to do anything useful.

I have the binaries as arrays of bytes in the Post Install. I convince VIPM to not include the binary dependency and then write out the binary from the Post Install. You can check in the Post install which bitness has invoked it to write out the correct bitness binary. Not sure if that would work on Linux though.