printer / text mode version libgz example ***

index
-summary
-history
-testscript
  perl / python
problems
-with callframes
-with structures
-largefile seeks
-broken builds
systems
-freeBSD/darwin
-linux/solaris
-64on32 mix
-distro makers
-win32/other (2)
libraries
-libc ..(3264)
-zlib ..(-32-)
-gtk2 ..(-64-)
converting
-old non-off_t code
-going largefile
-longlong default
-face dualmode
-make twinlibs
-and defend (it)
programming
-largefile default
-off_t in headers
-make export64
-find mismatch
-the autowrappers
-environ changes
-best practice?
old library
-dualmode renames
-the extra function
-largefile64_source
-glibc headers
-libgz example ***
new library
-dual export
-largefiles win32
-compat32 calls
-compat32 library
-long32 dualmode
links
-some quotes
-sitemap / mpl
-large.file Group*
-ac-archive Site*

 

 

 

(C) 2010-03-28 <guidod>
 Guido U. Draheim

LibGZ Example Project

The LibGZ is derived from the ZZipLib library - in the latter ZIP-files can be handled like a filesystem complete with directories and (transparently compressed) files. The LibGZ library will only provide for a GZ_FILE handle that allows to transparently read gzipped files as if they were not compressed at all.

This example gives you an overview how to create a library that is similar to the stdio libary while providing the same dualmode binary library. So there is really some "filelength64" / "filelength" pair of functions in the binary distribution while the example program "gzlib.c" only references "filelength". Looking into the resulting binary "gzlib.exe" shows that it does call to "filelength64" - in other words, it was pushed into the largefile64 mode.

You can download the source tarball in the ZZipLib download area named like libgz-0.1.0.tar.gz. Using "rpm -ta" you can easily turn this into a proper Linux RPM archive. The sources have been prepared for the WIN32 case (any comments welcome on this part). You can have a look at the sources directly in the SCM at
===> http://zziplib.svn.sourceforge.net/viewvc/zziplib/trunk/libgz-0/.

===> Copy it, Modify it, Use it in your own code!


Additional notes

  • the functions of libgz are named like "gz_fopen" (with a "gz_" prefix) where they should be in the place of "fopen". Apart from the general "gzio.h" header file there is also "gzstdio.h" that replaces the stdio.h fopen() call with the gz_fopen call such that some simple stdio source code could be switched to libgz easily.

  • I you do compare the "gzopen" / "gzread" functions from ZLib then you will find a similar approach in the "zlib" library - but (1) for one argument its implementation is far too complex to serve as template code and (2) for another argument: zlib did never have largefile64 support and when they introduced it (a few days before this text written) it occurred that they got their implementation of LFS fairly wrong. I guess they did not have a look at this website?

    The effect will be that there will be no largefile64 libz in any Linux distribition very soon now. Reading files beyond 2GB will still not be possible - so if you want to read "*.gz" files then this libgz library is still the better choice because it compiles as a largefile64 binary by default. Just as recommended.

  • The source code uses the largefile-sensitivity check - by comparing sizeof(long) and looking sizeof(off64_t) as detected by autoconf. This makes it so that on a 64bit platform there is no RENAMED64 symbol and no dualmode binary. To give it a test anyway you can install a 32bit gcc (on Opensuse: `zypper install gcc-32bit zlib-devel-32bit`) and run "sh configure --with-32bit".