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
