ZLIBC FREQUENTLY ASKED QUESTIONS

The latest released version is zlibc-0.8.

Zlibc breaks strace-3.0
Zlibc breaks foo program, what should I do?
Dvips and xdvi are unable to use zlibc
Program foo is unable to use zlibc
Zlibc is unable to follow symlinks to compressed files.
Can I also compress executables?
How should I report bugs?
Can I also compress libraries?
Which files shouldn't I compress?
Is there a {Free,386,Net}BSD port?
How can I remove zlibc when I don't want it any more?
Makewhatis doesn't notice that the manpages are already compressed.
When are changes in zlibrc files taken into account.
Does zlibrc recognize the names of scripts?
My system is dog slow since I installed zlibc?
With some programs, I get 'gzip: stdin: unexpected end of file' messages when chosing compressed file creation.
There are Segmentation faults during the compilation
Zlibc doesn't seem to work on my Elf compiled files

Zlibc breaks strace-3.0

Upgrade to strace-3.1, or apply the following patch:


diff -c strace-3.0.ori/defs.h strace-3.0/defs.h
*** strace-3.0.ori/defs.h	Sun Nov 20 13:12:41 1994
--- strace-3.0/defs.h	Sun Nov 20 13:12:06 1994
***************
*** 213,218 ****
--- 213,219 ----
  extern void set_overhead P((int));
  extern void qualify P((char *));
  extern void newoutf P((struct tcb *));
+ #define syscall my_syscall
  extern int syscall P((struct tcb *));
  extern void printxval P((struct xlat *, int, char *));
  extern int printargs P((struct tcb *));

[The syscall libc function is redefined by strace, resulting in a clash. This patch makes strace use my_syscall instead.]

Zlibc breaks foo program, what should I do?

Try running it with the environmental variable LD_ZLIB_DISABLE set to 1. Or with a 'commands "foo" use disable' line in your zlibrc.
If that doesn't help, set the LD_ELF_PRELOAD (or LD_AOUT_PRELOAD) variable to ":" .

Dvips and xdvi are unable to use zlibc

Apparently, some versions of dvips and xdvi are programmed in a way to directly use the system calls, instead of using the stubs in libc. Thus zlibc cannot hook into it. Fortunately, dvips and xdvi seem to be the only programs in the tex suite which does this, so you can still compress all tex related files, except those which live in /usr/lib/texmf/dvips. Upgrading to a more recent version of xdvi and dvips might help also.

Program foo is unable to use zlibc

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.
Check wether foo is dynamically linked. 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, zlibc is not going to work with that program. (For gcc an bash most binary distributions are dynamically linked.)
Try running it with the environmanetal variable LD_ZLIB_VERBOSE set to 1, and note the output.

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

Can I also compress executables?

Zlibc cannot use compressed executables. However there is another program, tcx which can do this. 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)

How should I report bugs?

Make sure that it is indeed a bug. Read all the documentation and the FAQ. If you are unable to read the manpages because of a buggy man, disable zlibc for man. See FA-question 2 for details.
This way, you can fix the man-problem temporarily, until you get a working version of man. Not everything is covered in this FAQ, some things are only mentioned in the manpages, INSTALL and CAVEATS files.
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.
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 LD_ZLIB_VERBOSE env. variable set and note the output.
You may also run the program under strace and note the output. (You'll need to apply the patch from question 1 to strace)
Tell me where you got the (client) program from.
My mail address is Alain.Knaff @ poboxes.com

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)

Which files shouldn't I compress?

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, ...
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.
Shared libraries (.so)
Executables (get tcx to do that)

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

Not yet. However, I have heard that BSD shared libraries are very similar to SunOS or ELF shared libraries. So when porting it to BSD, you might want to start from the Sun or ELF version.

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

Buy a huge disk :-)
Uncompress your compressed files with gunzip.
unset LD_ELF_PRELOAD, or remove it from /etc/ld.so.preload
ldconfig -l libc.so.4.x.y, where libc.so.4.x.y is your most recent non-zlibc library
Reboot
After rebooting, remove libc.*.z.* files out of /lib .

Rebooting is needed, because as long some programs still use zlibc, the space is not reclaimed from the filesystem after removing libc.*.z.* Be sure not to run ldconfig out of /etc/rc/rc.d before doing this, because this would undo step c. If you removed the zlibc before rebooting, the lost space will be reclaimed at the next fsck.

DON'T RUN FSCK BY HAND ON A READ WRITE MOUNTED FILESYSTEM. This might corrupt your data. I suggest you just wait until the mount count expires and the fsck is done automatically. Or if you are short on space, boot linux from a ramdisk floppy, and fsck your hard disk from there.

Makewhatis doesn't notice that the manpages are already compressed.

Disable the zlibc for makewhatis. (i.e. run it always with the following command line:


 LD_ZLIB_DISABLE=1 makewhatis
)

When are changes in zlibrc files taken into account.

If your zlibrc file is still syntactically correct, all changes in the zlibrc files are taken into account at least for the programs which are started after the change. To check the correctness of your zlibrc file, set then environmental variable LD_ZLIB_VERBOSE to 1. This prints lot of informational messages, and also error messages.

For the ELF version, the zlibrc files are parsed as soon as the program is started. Changes in zlibrc files affect only programs that are started after the change.

For the non-ELF versions, the zlibrc files are parsed by every program whenever they are first needed, i.e. when the programs first tries to uncompress a file. Thus changes MAY affect already running programs, and CERTAINLY affect programs which are started after the change.

Does zlibrc recognize the names of scripts?

No. In a script the current command name is always the name of the shell, thus zlibc cannot recognize the name of the script itself.

My system is dog slow since I installed zlibc?

How much memory do you have? I have 16M and it runs fine in it.
Try using temporary files as a default method. This can be achieved by putting the following lines into your zlibrc:
```
  commands default use "nopipe"
  ...
  class "nopipe"
  usetmpfile
```
( The dots mean that the commands line should go at the beginning of the file, and the class definition at the end. See manual pages for details)

With some programs, I get 'gzip: stdin: unexpected end of file' messages when chosing compressed file creation.

What probably happens is that the program uses the obsolete 'creat' call. The 'creat' call is not as flexible as open, and so the program needs to open the file twice:

 close(creat(file, mode)); /* create the tmp file */
 open(file, O_RDWR, mode); /* open it in the desired mode */

The creat call creates the compressed file. A gzip is started in the background to do this (it has to run paralelly to the main program, just in case that program tried to write to the file descriptor.) Because the open follows immediately afterwards, the creating gzip may not yet been done. Open spawns an uncompressing gzip, which finds an invalid compressed file. This gzip prints that error message. This error message is bening, as the file was empty anyways.

In order to avoid it, try to find out the relevant file using strace or LD_ZLIB_VERBOSE, and switch compression off for it. Very often these are just temporary files. Putting the following line in the class of the offending program thus clears away most of these messages:

 dir "/tmp" no-create-compressed

[This is a good idea anyways, because usually you don't want tmp files to be compressed.]

There are Segmentation faults during the compilation

If you get mysterious segmentation faults during the compilation, the cause may be that you used the same object file extension for ELF and a.out, and that the linker is getting confused by the presence of files of the wrong binary format. See Binfmt.doc for details.

Zlibc doesn't seem to work on my Elf compiled files

Make sure they are linked dynamically. The new binutils compile all files statically if there is no libc.so symlink pointing to libc.so.5 in /lib or /usr/lib.

Last modified: Sun Dec 15 13:24:46 MET