 ZLIBC FREQUENTLY ASKED QUESTIONS
 ================================


1. Zlibc breaks "man".

 man-1.0 is buggy. It contains a routine which returns a pointer to a
automatic (local) variable. Under normal circumstances this bug isn't
visible because the stack doesn't "go deep enough" after this routine
to clobber this variable. However, with zlibc it DOES go deep enough,
and thus, this variable gets overwritten before it is used.

 Fix: Get man-1.1B from tsx-11.mit.edu:/pub/linux/binaries/FSF/man11B.taz
  or: Put 'commands "zlibc" use disable' in your zlibrc
  or: Apply the following patch to your man-1.0 sources, and recompile:

*** man.c	Sat Mar 28 04:08:24 1992
--- man.c.new	Sun Nov 28 13:54:30 1993
***************
*** 768,774 ****
  {
    FILE *fp;
    char buf[BUFSIZ];
!   char ult[BUFSIZ];
    char *beg;
    char *end;
  
--- 768,774 ----
  {
    FILE *fp;
    char buf[BUFSIZ];
!   static char ult[BUFSIZ];
    char *beg;
    char *end;

 N.B. This buggy man is included in the Slackware distribution. The
maintainer of Slackware has been contacted, and in one of the next
releases it will be fixed.
 ( BTW, all versions of xman work too.)

2. Zlibc breaks foo program, what should I do?
 
 a. Try running it with the environmental variable ZLIB_DISABLE set.
Or with a 'commands "foo" use disable' line in your zlibrc.
 b. If ZLIB_DISABLE doesn't fix things, make a symlink from libC.so.4
to libc.so.4.4.4 (or whatever your most recent non-z libc is). Then
replace, in program foo, the string libc.so.4 with libC.so.4 (Emacs is
able to edit binary files.)


3. Zlibc doesn't do anything on my system.

 a. Be aware zlibc doesn't compress the files by itself. You need to
compress the files manually using gzip. Zlibc then uncompresses them
on the fly for all executables who need them.
 b. Are you using the binary distribution? If so, make sure your gzip
is installed installed in /usr/bin/gzip, and creates compressed files
with a .gz extension (old versions of gzip create files with a .z
extension) If your gzip lives elsewhere, make a symlink or use de
ZLIB_UNCOMPRESSOR env. variable; if it uses a different extension,
upgrade or use the ZLIB_EXT env. variable.
 N.B. The configure script of the source distribution tries to
autodetect various parameters ( path of gzip, and extension of
compressed files) and proposes these as defaults. Don't assume that
these same defaults were used to make the binary distribution. The
file config.h generated by the configure script is included in the
binary distribution.
 c. Make sure that your libc.so.4 is correctly symlinked to the zlibc.
(libc.so.4.4.4.z0.4)


4. Program foo is unable to use zlibc.

 a. Try restarting the foo program. Indeed, only programs started
after you installed zlibc can use it. For instance, the shell where
you installed zlibc from won't use it (no filename completion). The
simplest way of restarting every program is to reboot the machine.
 b. Check if foo is dynamically linked ( against a .4 library on
Linux) Be aware that especially on Suns, many programs are still
statically linked. Those can't use the zlibc. The ldd (in the ldso
package) program lists all the dynamic libraries, that a program is
linked against. If you get an empty list, or a list which doesn't
contain libc.so.4, zlibc is not going to work with that program. (For
gcc an bash most binary distributions are dynamically linked.)

 c. Try running it with the environmanetal variable ZLIB_VERBOSE set,
and note the output.


5. Zlibc is unable to follow symlinks to compressed files.

 If you have a file named foo, and a symlink bar pointing to it, you need
to change that symlink when compressing foo:
> ls -l
total 2
lrwxrwxr-x  1 knaff           3 Nov 22 17:51 bar -> foo
-rw-rw-r--  1 knaff           6 Nov 22 17:51 foo
> gzip foo
> rm bar
rm: remove bar? y
> ln -s foo.gz bar.gz


6. Can I also compress executables?

 Zlibc cannot use compressed executables. However another program, called tcx
can. To save most diskspace, use the two programs together. (zlibc is able
to use compressed datafiles, but not executables, and tcx is able to use
compressed executables, but not datafiles)


7. How should I report bugs?

 a. Make sure that it is indeed a bug. Read all the documentation and
the FAQ.
 b. Try finding out the version of the client program which triggers
the bug. Many programs support a -v or -V option to print the version.
 c. Describe the problem as precisely as possibly, with error messages
etc.  Don't just say "Program foo bombed out". Try also running it
with the ZLIB_VERBOSE env. variable set and note the output.
 d. Tell me where you got the (client) program from.
 e. My mail address is Alain.Knaff@imag.fr


8.  Can I also compress libraries?
 
 You can compress static libraries (.a) and shared libraries stubs (.sa) 
without any problems. However, you can't compress shared library objects (.so)


9. Which files shouldn't I compress?

 1. Files associated with the boot and shutdown process, especially if your
gzip doesn't live on the root partition. These files are /etc/rc, /etc/inittab,
/etc/fstab, ...
 2. Files which are smaller than 1024 bytes (or 512 bytes on a Dos fs). 
Filesystem space is allocated in blocks of 1024 bytes, so if your file is
already smaller than that, you don't win anything by compressing it.
 3. Shared libraries (.so)
 4. Executables (get tcx to do that)


10. Is there a {Free,386,Net}BSD port?

 Not yet. However, I have heard that BSD shared libraries are very
similar to SunOS shared libraries. So when porting it to BSD, you
might want to start from the Sun version. Be aware that shared library
support in BSD is pretty recent, so there might still be very many
statically linked binaries around.


11. How can I remove zlibc when I don't want it any more?

 a. Buy a huge disk :-)
 b. Uncompress your compressed files with gunzip.
 c. Run the uninstall script (Or use ldconfig -l libc.so.4.x.y, where
 libc.so.4.x.y is your most recent non-zlibc library)
 d. Remove libc.*.z.* files out of /lib
