DL-Compat
---------

This library makes dl functions like dlopen available for Windows and other
systems that don't have the dl-library.

It has its own PE-COFF (Windows Binaries) reader, and it handles the relocation.
It allows back-linking without any problems (DLLs on Windows do _not_ allow
this) and the libraries can be compiled with unresolved symbols. Because of 
this, it feels the same as the Unix-way to handle libraries.

Also, this library is 100% POSIX compatible. In the future it might have more
functions then defined by POSIX, but currently it isn't much more. For sure 
it does exactly as POSIX tells what such a library should do.


Targets
-------

Currently the only known working target is Windows. If you can make this
library to compile on an other system, make sure to tell us.


Usage
-----

Compile and install the library:
 ./configure
 make
 make install

Link it to your executable:
 LDFLAGS += -ldl-compat
Or if you want it static:
 LDFLAGS += libdl-compat.a

And simply use the API just like you would use dl functions:

 void *dlopen(const char *filename, int flag);
 char *dlerror(void);
 void *dlsym(void *handle, const char *symbol);
 int dlclose(void *handle);

(yes, they have the same name, because you should always use one of the two,
never mix them!)

You should use dlc-ld to link your dlc-library. It takes care of any needed
deps by the library itself. When dlc starts searching for your library, it 
tries the name as a path first, then it searches on DLC_PATH, LD_LIBRARY_PATH,
PATH and as final resort, it tries to load it via LoadLibrary, in the case it 
is a dep that needs to be loaded. When the library still can't be found, it
aborts.

One word of advise: because there is no way to see if a symbol is an __imp__
symbol (Windows stuff you don't want to know about ;)), we check if the name
of a symbol starts with __imp__. Therefor, if you nick your own symbol like
this, while it isn't a real imp-symbol, a lot of weird and strange stuff will
happen. So a word of advise: don't do it.


Problems & Bugs
---------------

A known limitation is that the system runs on i386 only. In theory it could
be ported to other systems with a small amount of efforts.

At this point there are no known bugs besides the ones listed in BUGS (if any).
If you find one that isn't listed there, or you notice a problem, feel free to
contact us:

Patric 'TrueLight' Stout: truelight at libgpmi.org
Tibor 'Igor2' Palinkas:   igor2 at libgpmi.org

And we will try to help you out.


History
-------

The reason this project exists is the windows port of GPMI. GPMI makes good
use of the Unix possibilities for shared libraries. While porting it to
Windows we ran into the problem of DLLs. DLLs are simply a piece of crap. 
So, we searched for a solution, and found eDLL. eDLL is a wrapper around 
'bfd' that allows what is described above. Sadly enough, eDLL did much more
than what we need.

Therefore we decided to take the parts from eDLL we needed, and put them
in a new library. The library should _only_ provide of the four functions
that dl supplies: dlopen, dlclose, dlerror and dlsym. So, this library
was born.

Later on, we noticed that 'bfd' had more bugs then we could find ways around
for (example: on some systems it told us that symbol->section was NULL, while
this should be impossible in all scenarios, according to 'bfd' manual). So we
dropped 'bfd' totally, and created our own backend reader. Currently it only
supports PE-COFF, but it shouldn't be too hard to extend it.


Acknowledgments
---------------

We want to thank Alexis Wilke for the great work on eDLL. eDLL made clear to
us how to make a wrapper around bfd and allowed us to create this library.
Later on he also showed us that it was possible to write our own PE-COFF reader
which we did. So thank you very much for your effort and time on eDLL!


References
----------
GPMI: http://www.libgpmi.org/
BFD: http://sources.redhat.com/binutils/docs-2.15/bfd/index.html
eDLL: http://edll.sourceforge.net/