Problem on appending files on a zip file on RT

[jramon]

Hello,

I'm using OpenG Labview ZIP Library 4.0.0-2 (and also 2.5.1-2 with the same problem) on labview 2009 SP1.

I try to append a new file to an exixting zip file, using for instance the vi attached. When I run the vi on Windows, it works properly, and the output .zip file contains both input files. The problem arises when I run exactly the same vi in the cRIO 9012 RT controller. In that case the .zip file contains only the first input file and the error code 7 (message: ZLIB Open Zip Archive__ogtk.vi in ZLIB Compress Files__ogtk.vi->zip.vi) appears in indicator "error out 2".

I've tried to do the same using the ZLIP Open Zip, ZLIB store and ZLIB Close Zip, and I had exactly the same problem.

Does anybody have any suggestion to solve this problem?

Thanks,

Joan Ramon

zip.vi

[jgcode]

I'm using OpenG Labview ZIP Library 4.0.0-2 (and also 2.5.1-2 with the same problem) on labview 2009 SP1.

I try to append a new file to an exixting zip file, using for instance the vi attached. When I run the vi on Windows, it works properly, and the output .zip file contains both input files. The problem arises when I run exactly the same vi in the cRIO 9012 RT controller. In that case the .zip file contains only the first input file and the error code 7 (message: ZLIB Open Zip Archive__ogtk.vi in ZLIB Compress Files__ogtk.vi->zip.vi) appears in indicator "error out 2".

I've tried to do the same using the ZLIP Open Zip, ZLIB store and ZLIB Close Zip, and I had exactly the same problem.

Does anybody have any suggestion to solve this problem?

Hi Joan

Are you including the correct support files on the RT system?

VxWorks Support (Additional Installation Steps)

For VxWorks support, after installing the lvzip package, you should ftp "<LabVIEW>\user.lib\_OpenG.lib\lvzip\lvzlib.out" to the RT controller into ni-rt\system.

[jramon]

Hello,

Yes, I include these files in the RT system. In fact, when I create a new zip file on the RT, it works correctly. Do you tink that the problem may be in the lvzlib.out library?

Joan Ramon

Hi Joan

Are you including the correct support files on the RT system?

[Rolf Kalbermatter]

Do you tink that the problem may be in the lvzlib.out library?

I'm afraid so but don't have a quick idea what the problem would be. Debugging on VxWorks is also a pain, since I don't have the integrated VxWorks development environment available (which costs $ and I can't justify this as the whole library and especially the VxWorks port is simply voluntary work).

[jramon]

We have just recompiled the lvzip project for VxWorks using the gnu tools (http://zone.ni.com/devzone/cda/tut/p/id/5694) and the latest .c and .h files. After changing all the "//" comments from the .c files to "/* */" we could succesfully obtain the new lvzip.out library. This new library (attached here) works correctly and has no longer the problem.

Joan Ramon

lvzlib.zip

I'm afraid so but don't have a quick idea what the problem would be. Debugging on VxWorks is also a pain, since I don't have the integrated VxWorks development environment available (which costs $$ and I can't justify this as the whole library and especially the VxWorks port is simply voluntarily work).

[Rolf Kalbermatter]

We have just recompiled the lvzip project for VxWorks using the gnu tools (http://zone.ni.com/d...a/tut/p/id/5694) and the latest .c and .h files. After changing all the "//" comments from the .c files to "/* */" we could succesfully obtain the new lvzip.out library. This new library (attached here) works correctly and has no longer the problem.

Well I had submitted a few zlib related fixes lately that haven''t made it yet into the official upstreams zlib library, so those changes could be the reason that it now works. I didn't expect those changes to have such an influence though, as it was really about troubles when compiling as 64bit code.

But I'm baffled about the need to change comments! I have compiled this library with the same toolchain and no modifications to the source code without any compile errors about comments. And I would rather leave the comment style as it is, since most of the files are just taken from the zlib project and changing them each time the zlib project has modified files is simply to painful. Can you give some information as to what errors you got from the // comments

One guess I have might be that the updated_gcc toolchain that is now on the NI page incorporates a new gnu version that stumbles over the // comments when compiling .c files, as // comments were originally only a C++ feature. But that would be a rather awkward change, since most C compilers nowadays accept both comment styles anyways and it seems also part of the official C99 standard, which is for standard C compilers. So not sure why GNU would revert a feature that is officially declared in the C99 standard.

[jramon]

I don't know the reason why now the library works, but a possible reason is that the date of the lvzip.out (23/12/2008) in the official release is much older than the date of the lvzip.dll (03/09/2009). Is it possible that the lvzip.out was not updated as the lvzip.dll was?

The problem with the // comments is in fact a minor problem. This kind of comments appear only about 20 times, and it lasts 5 minuts to change it.

The compiler we used is the updated_gcc downloaded from NI you mention, and the error we obtained was a syntax error at the line after the // comment. Maybe the compiler can behave ok with // comments using the appropiate option.

Well I had submitted a few zlib related fixes lately that haven''t made it yet into the official upstreams zlib library, so those changes could be the reason that it now works. I didn't expect those changes to have such an influence though, as it was really about troubles when compiling as 64bit code.

But I'm baffled about the need to change comments! I have compiled this library with the same toolchain and no modifications to the source code without any compile errors about comments. And I would rather leave the comment style as it is, since most of the files are just taken from the zlib project and changing them each time the zlib project has modified files is simply to painful. Can you give some information as to what errors you got from the // comments

One guess I have might be that the updated_gcc toolchain that is now on the NI page incorporates a new gnu version that stumbles over the // comments when compiling .c files, as // comments were originally only a C++ feature. But that would be a rather awkward change, since most C compilers nowadays accept both comment styles anyways and it seems also part of the official C99 standard, which is for standard C compilers. So not sure why GNU would revert a feature that is officially declared in the C99 standard.

[Rolf Kalbermatter]

I don't know the reason why now the library works, but a possible reason is that the date of the lvzip.out (23/12/2008) in the official release is much older than the date of the lvzip.dll (03/09/2009). Is it possible that the lvzip.out was not updated as the lvzip.dll was?

The problem with the // comments is in fact a minor problem. This kind of comments appear only about 20 times, and it lasts 5 minuts to change it.

The compiler we used is the updated_gcc downloaded from NI you mention, and the error we obtained was a syntax error at the line after the // comment. Maybe the compiler can behave ok with // comments using the appropiate option.

Well the actual code that adds appending support to an archive was incorporated around 2006 or so, so it should definitely have been in the .out library you had first used. There were other changes to the c source including the change to zlib 1.2.5 but not really between the two dates you show. But it is good to know that it the current source seems to work fine now. I will try to go through all targets and build a new shared library file for them in the next few weeks. This would be by now: Windows x86, Windows x64, Mac OS X x86, Mac OS X PPC, vxWorks 6.1, vxWorks 6.3, Linux 32 bit. A serious series of toolchains that one can't install on one computer or even two or three alone. And Mac OS X x64 is probably coming too, as the newest OS X doesn't seem to allow to startup in 32 bit mode anymore.

I'll check about the comments. If they are not in the zlib files I'm going to change them, otherwise I'm not sure what is the right solution at the moment.

[Rolf Kalbermatter]

I have played a little with the vxWorks toolchain. The reason that the // comments are not accepted is that the example vxWorks makefiles that I used as a template for my lvzip makefile do specify the -ansi switch to the C compiler. This reverts to C90 and disables C99 features such as // comments and inline keyword explicitly. Removing that allows compilation without problems but I'm not sure if the resulting shared library is still fully operational for the LabVIEW realtime target as it also has a few effects in terms of compiler builtin symbols that are enabled and are in C90 replaced with library symbols that the compiler will link the resulting object files to. This library shouldn't use any of those symbols but not sure if there are side effects.

[mmckenna]

Well the actual code that adds appending support to an archive was incorporated around 2006 or so, so it should definitely have been in the .out library you had first used. There were other changes to the c source including the change to zlib 1.2.5 but not really between the two dates you show. But it is good to know that it the current source seems to work fine now. I will try to go through all targets and build a new shared library file for them in the next few weeks. This would be by now: Windows x86, Windows x64, Mac OS X x86, Mac OS X PPC, vxWorks 6.1, vxWorks 6.3, Linux 32 bit. A serious series of toolchains that one can't install on one computer or even two or three alone. And Mac OS X x64 is probably coming too, as the newest OS X doesn't seem to allow to startup in 32 bit mode anymore.

I'll check about the comments. If they are not in the zlib files I'm going to change them, otherwise I'm not sure what is the right solution at the moment.

Dear Rolf:

Thank you for your efforts. I was following the other thread on lvzip and 64-bit labview. Do you think you'll be posting the windows x64 library soon?

Thanks

Mark

[Rolf Kalbermatter]

Dear Rolf:

Thank you for your efforts. I was following the other thread on lvzip and 64-bit labview. Do you think you'll be posting the windows x64 library soon?

Thanks

Mark

I had created a 64 Bit version last year already using the Windows SDK command line compiler but it crashed somewhere. And I still need to get a 64bit development version of Visual Studio installed to do some useful debugging. So that will take some time and probably some fiddling around to get working properly.