
License: this file and all the files in the tests suite
         are public domain.


Welcome to the tests suite of the EDLL.

This directory includes several sub-directories which are
tests to be used against the EDLL library.

The following briefly describes each test:

edll-c	this test is for C users who do not need to use the
	ltdl library; if you don't need C++ and are not looking
	into porting your application to Unix (Linux or otherwise)
	then look in this example

edll-bss
	this test ensures that COMMON sections are properly
	managed; it creates an image of a circle

edll-two-bss
	this test is an extension of the edll-bss test which
	checks the COMMON section and the .bss section and
	will make sure that we can load two such sections from
	two different plugins and everything still works; it
	also shows how you can load a plugin, use it, and then
	load another

c	this test is for C users; if you don't need C++
	functionality (constructors/destructors, etc.)
	then look in this example

ctor	a simple example showing how C++ objects defined
	as globals have their constructors (on load) and
	destructors (on close) automatically called

dep	this example shows a plugin which depends on
	another; the main application (startup) only
	loads the main plugin; the .load section of
	that plugin defines the name of the other to
	be loaded automatically by the EDL

merge	in larger projects, it is certainly wise to
	create plugins out of multiple object files;
	this means you will need to merge the
	different object files to generate the plugins;
	this is (currently) done with ld -r <files>
	and in the end the main app. only loads one
	file

blnk	this sample shows how the back linking work
	like a charm without you having to do anything
	about it; the plug-in calls a function in
	the dependency which itself calls a function
	in the plugin; thus you will avoid rewriting
	functions or linking functions multiple times
	to different modules

good_version
	this is used to make sure that when the
	executable and the module have the exact same
	version the executable can load the module
	without any errors

bad_version
	this is used to make sure that an executable
	and module of different versions don't work
	together (i.e. the load from the executable
	must fail)

