ZLIBC FREQUENTLY ASKED QUESTIONS
The latest released version is zlibc-0.9e.
* 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?
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)
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 Mar 23 09:12:12 MET