This is dl version 1.5.1, created 24-Sep-92.

Differences with 1.4:
- You can pass the name of a #! script as binary name and dl_loadmod
  will find the name of the real binary.
- The .ld file is created under a temporary name and moved to the right
  place later (so multiple processes loading the same object don't
  bite each other so much)

------------------------------------------------
This is version 1.4 of dl, a dynamic loader for Irix, created 30-Jul-92.

The main change is that there is a new interface, dl_loadmod_mult()
which allows you to obtain more than one address from the newly loaded
module.

Dl has also been adapted to work with the new libmld library which
missed some features of older libmld implementations. Dl has been
tested under 4.0.2 and 4.0.5, but I have no reason to believe that it
won't work with older releases.

A workaround for incremental loading has been hacked in. The idea was
provided by Casper Dik: if we are in incremental mode (when the user
has called dl_setincr() and calls dl_loadmod() with a null filename)
we make a pass over the string table and remove occurrences of _end,
_etext and _edata. Gross, but it might work.

Finally, dl now uses atexit() to attempt to remove temporary
executables when the program exits.

-------------------------------------------------------
Here is the README for version 1.3:

A few bugs have been fixed, the main one being that object files with
an empty bss segment didn't load correctly.

Since linking can take a long time a message is now printed to stderr
while linking the object. There is a routine dl_setmessage() to set
the message printing routine, and a routine dl_nomessage() is also
provided that doesn't print anything.

Support for incremental loading has been added. It doesn't work,
unfortunately, because SGI ld refuses to take an incrementally linked
file (one created with an 'ld -A ...' run) as the input to another
incremental link (i.e. as argument to the '-A'). It complains about
'-A file defines loader-defined symbol _etext'. Careful examination of
symbol tables didn't point me at the problem, so I remain open to
suggestions.

I received a note from Brian McClendon from SGI, bam@sgi.com, who said
that there was a bug in the R4000 that might influence this package on
the Crimsons. I don't fully understand what the problem might be, but
here's the note:

	This is just a note since you're doing a package on dynamic loading.

	There is a bug in the R4000s that we work around in the kernel, but
	the work-around depends upon executing .text only.  If you mmap
	and execute .data, you may run into this problem.  To avoid it,
	remind all R4000 users to compile dynamically linked code 
	with the -Wb,-dwalignbr flag.

	Later we will make the loader fix this for all code, but for now
	the ccom-piler needs to know.

--------------------------------------------------------
Here is the README file for version 1.2:

The only significant change with respect to version 1.0 is that the
load addresses for the file are now computed as a hash function from
the file name, and that memory management is done using a bitmap. The
effect of this is that if you often load modules in random order the
caching will still work. A minor (but annoying) change is that
dl_ldzfilep has gotten a second parameter, which is needed due to some
ununderstood weirdness in the ldfcn library.

--------------------------------------------------------
Here is the 1.0 README file:
This is the first release of dl, a dynamic loader for Irix.

It may or may not run on other unix systems with a little hacking. If your
system has the ldfcn routines (-lmld) and either SysV shared memory or the
mmap() system call you have a fair chance.

The library has been tested under Irix 4.0.2 on an Indigo, but it
should probably work on all machines under 4.0.2, and probably under
older releases as well (it has been known to work under 4.0 and 4.0.1
on various platforms). Please let me know if you use this on another
platform (also if it didn't work).

There is a tiny test program in 'test', try it.

I'm not too happy with the current interface, so please feel free to
comment on it. The main problem is that you currently have to choose between
a very high-level interface or a very low level one. Something in between
would be nice.

If there is enough interest (and some feedback on a better
interface) I'll release a new version somewhere in the future.

Jack Jansen, Centrum voor Wiskunde en Informatica, Jack.Jansen@cwi.nl
