Re: [MiNT] MiNTLib 0.51

["Guido Flohr" <gufl0000@stud.uni-sb.de>]

Hi Julian!

On Fri, May 21, 1999 at 09:31:50PM +0200, Julian Reschke wrote:
> > The problem is that the reference to "open" would get resolved within the
> > shared library and so you need another name for the library function.
> 
> a) You could habe a zlib-enhanced version of libc which would have zlib
> directly built in. This would be a compatible replacement of a libc.slb, and
> users could decide during setup which one to install.
> 
> b) It also might be possible to hook zlib.slb "between" the program and the
> original "libc.slb", I'll have to check how this could be done...

You describe more or less the way that the zlibc is intended to use.  But
I have to admit that the whole concept (not yours, the zlibc in general)
is a little suspect to me.  I prefer the libz which simply provides all of
gzip's compression algos.  This is faster and more reliable.

My problems with the zlibc don't have to do with open/close/read/write,
that's relatively straightforward.  Problematic are chmod, chown, link,
symlink and so on.  The zlibc provides some relatively complicated
configuration mechanism to deal with that but I don't think that ordinary
users will become very happy with that.

Apart from that, it would work even without a shared lib.  You simply have
to put that lib into your specs file before -lc to become a standard
library.  If you relink a program with that you will end up with a new
program that can handle compression/uncompression on the fly.  I have for
example relinked my linker, archiver and nm now I can gzip my
libdirectory. But I repeat that I prefer to leave this decision to the
programmer and simply use gz_open or gz_read (from libz) instead whenever
appropriate.

When we have shared libs working we can have another look.

Ciao

Guido
-- 
http://stud.uni-sb.de/~gufl0000
mailto:gufl0000@stud.uni-sb.de