openG Zlib library not working in Labview 2018 64bit

[wiebe@CARYA]

---

@aartjan wrote:

Wow, you guys really go to the bottom of things!

---

Guess I have to now...  Not sure if all this information is reflected in my code.

To make things worse, I also use the dll on MacOS...

I have been thinking about using the zlib source code to compile my own dll with just the deflate function. Starting to sound like a good idea, even if only to have a fallback scenario.

[Cranky]

Awesome! I've been having problems with the Sharp Zip library and can't get any traction on a solution. I'll see if this fixes it.

Edit: Can't install it on LV2014. I have 2014 RT installed, not sure what this means...

Main Package Name: OpenG ZIP Library v4.1.0-b2
Package Name with Error: OpenG ZIP Library v4.1.0-b2
Error Message: VIPM could not install the package oglib_lvzip-4.1.0-b2 .
Error Code: 5
Error Source: System Exec.vi. Command was "C:\Program Files (x86)\National Instruments\LabVIEW 2014\user.lib\_OpenG.lib\lvzip\RT Images\setup.exe"
===============

[rolfk]

Yes in order to download files from lavag you would need an account.

But see in this thread for an alternative download of that package. The package is an OpenG package (*.opg), which was the predecessor to VIPM and VIPM inherited the ability to deal with such packages from the OpenG Package Manager, from which it was derived.

It seems that the installer program that I added in there to install LabVIEW RT versions for this library might be having trouble on some modern Windows 10 systems due to missing runtime libraries. I used at that time Inno Setup which seemed like a good idea, but it seems that their installer uses a particular runtime library version that might not be present on new Windows 10 systems.

As long as you do not want to install support for the LabVIEW realtime targets you can ignore that error. Or did you maybe dismiss the elevation dialog that should pop-up when this setup.exe program is run? It requires elevated privileges to be able to store the necessary files in the location where NI Max can find them to be able to install them on the target. Maybe starting VIPM as administrator would help to avoid that error!

By the way, I'm currently in the process of finalizing a new version of this library. Most of the work for Windows, Mac and Linux is done, but I still need to do some more testing and I'm also trying to find an alternative way to install the RT support.

[Cranky]

Thanks for the quick reply. I edited my reply about 4 times, apologies if that caused confusion.

I'm running Win10 1709. There's lots of weird problems since upgrading from Win7, most of which I can't get resolved through my IT department.

I tried running as an admin, still got the error. No elevation dialog either. I can see if IT can run it as admin remotely. It fails to install, so I can't just dismiss the error.

Anything I can do to help with the rollout or testing of the new version?

Thanks!

[Cranky]

I also looked for the target of the system exec and it's not present in 4.0.0-2. The lvzip folder appears for less than a second during install, just before the error message, so I can't see if it's actually present or if it can be called as an admin outside of the installer.

[rolfk]

That is probably VIPM cleaning everything up after any error. Proper implementation in fact but it can be annoying in such cases.

[Cranky]

Doesn't look like a folder permissions error for copying. IT gave me full access to the NI folder tree and I still get the error when installing.

IT tried running VIPM as admin and it gave a different error--something about a vi reference and post-install--and still failed.

I guess I'll just wait on the official release then.

Thanks!

Cranky

[pauldavey]

My experience of using 7-zip was that it needed to be a GZIP file and not simply a zlib stream (which have different headers/footers).  But you can go to the trouble of wrapping the ZLib stream data (stripped of 2 bytes at the start and 4 bytes at the end) with an appropriate header (HEX: 1F8B 0800 0000 0000 0000 ) and footer (HEX: 0000 0000 0000 0000 ), write it to a file and then use 7Zip's command line and ignore 7Zip's complaint about the invalid checksum.  The hardest part is constructing the correct cmd string.

[wiebe@CARYA]

---

@pauldavey wrote:

My experience of using 7-zip was that it needed to be a GZIP file and not simply a zlib stream (which have different headers/footers).  But you can go to the trouble of wrapping the ZLib stream data (stripped of 2 bytes at the start and 4 bytes at the end) with an appropriate header (HEX: 1F8B 0800 0000 0000 0000 ) and footer (HEX: 0000 0000 0000 0000 ), write it to a file and then use 7Zip's command line and ignore 7Zip's complaint about the invalid checksum.  The hardest part is constructing the correct cmd string.

---

Thanks for sharing, but how is this on topic? AFAIK, this is about 'openG Zlib library not working on LabVIEW 2018 64bit'...

[rolfk]

---

wiebe@CARYA wrote:

---

---

Thanks for sharing, but how is this on topic? AFAIK, this is about 'openG Zlib library not working on LabVIEW 2018 64bit'...

---

It's somewhat on topic if you read the first post from this thread. But the thread has evolved into a discussion of the topic title rather than the underlaying technical problem at hand from the OP, who happened to try to use the OpenG ZIP library to solve his real problem.