new thoughts on dynamic libraries support

[Lisandro Dalcin]

After thinking hard how to follow Barry's concerns about "not add new
stuff", perhaps we could do things as to make 'private' the
PetscDLOpen/PetscDLClose low-level wrappers to platform's DLL API's.
But this would requiere some small changes to the way
PetscDLLibraryOpen() currently works.

For PetscDLLibraryOpen() to success, the dynamic library currently
have two requisites:

1) The library must me named libNAME[.???] , i.e. the filename must
begin with 'lib' prefix, but the extension (eg: .so / .dll / whatever)
is optional !!. If the filename does not start with 'lib', then
PetscDLLibraryOpen() fails!!.

2) The dynamic library must export a function
PetscDLLibraryRegister_NAME. If the symbol is not exported, then
PetscDLLibraryOpen() fails!!  BTW, Because of this constraint,
PFSTRING implementation is currently broken.

If Barry agree to make (1) and (2) optional (perhaps making
appropriate PetscInfo calls), then I would accept to make my new
PetscDLOpen/PetscDLClose stuff truly private to the src/sys/dll
directory.

If (1) and (2) are not made optional, then the PetscDLLibraryXXX() API
is not general enough. It would not be possible to dlopen almost any
library unrelated to PETSc. But PetscDLLibraryXXX() has some other
nice features, like automatic file retrieval, and automatic
register-in-linked-list of oppened libraries, that it would be great
to make this higher-level API usable in more general cases.




-- 
Lisandro Dalcín
---------------
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594