new thoughts on dynamic libraries support

[Barry Smith]

   When I added the PetscDLLibraryRegister_petscxxxx() approach
I never fixed the pfstring to use that model.

   This is all easily fixed I think, in fact adding the  
PetscDLLibraryRegister_petscxxxx()
will likely make it better than what it was.

    Barry

On Oct 20, 2008, at 5:16 PM, Lisandro Dalcin wrote:

> No, Barry, I was not clear enough.
>
> AFAIK, PFSTRING is broken at the time you want to actually create a PF
> of type PFSTRING. This PF type is implemented by compiling on-the-fly
> a new dynamic library called 'libpescdlib.so' (using a template file
> src/vec/pf/impls/string/cstringbase.c and calling 'make' via popen
> somewhere inside $TMP dir).
>
> The current implementation approach has three problems:
>
> 1) It only works if PETSc compiled --with-dynamic. But this could work
> even if PETSc is compiled with static libs, though that would require
> some extra cares (users executables should be built with appropriate
> flags for exporting symblols, like passing to the linker the flags
> '-Xlinker -export-dynamic' when building executables).
>
> 2) If you look at src/vec/pf/impls/string/cstringbase.c, there is no
> function 'PetscDLLibraryRegister_petscdlib' exported. Then the call to
> PetscDLLibrarySym() in  FStringCreateFunction() will fail.
>
> 3) Even if the above issues are fixed, PETSc opens dynamic libraries
> with RTLD_GLOBAL flags and then caches them in DLLibrariesLoaded list.
> Then I'm not sure if this will let you create more than ONE PFSTRING.
> If extra care is taken by using a mktemp-like routine, we still could
> have issues with the RTLD_GLOBAL (though I'm not sure).
>
> As you see, the PFSTRING implementation is somewhat broken, and this
> was never noticed because there are no tests for PFSTRING.
>
> BTW, You are completely right! Libraries (and specially dynamic) are
> really overwhelming ;-)
>
>
> On Mon, Oct 20, 2008 at 6:34 PM, Barry Smith <bsmith at mcs.anl.gov>  
> wrote:
>>
>> On Oct 20, 2008, at 1:49 PM, Lisandro Dalcin wrote:
>>>
>>> PetscDLLibraryRegister_NAME. If the symbol is not exported, then
>>> PetscDLLibraryOpen() fails!!  BTW, Because of this constraint,
>>> PFSTRING implementation is currently broken.
>>>
>>
>>  I don't understand why this would be. The PF stuff is in the Vec  
>> library.
>>
>> PetscErrorCode PETSCVEC_DLLEXPORT  
>> PetscDLLibraryRegister_petscvec(const char
>> path[])
>> {
>> PetscErrorCode ierr;
>>
>> ierr = PetscInitializeNoArguments(); if (ierr) return 1;
>>
>> PetscFunctionBegin;
>> /*
>>     If we got here then PETSc was properly loaded
>> */
>> ierr = ISInitializePackage(path);CHKERRQ(ierr);
>> ierr = VecInitializePackage(path);CHKERRQ(ierr);
>> ierr = PFInitializePackage(path);CHKERRQ(ierr);
>> PetscFunctionReturn(0);
>> }
>>
>> The PF is suppose to work in the same way as the IS, I'm guessing  
>> the IS
>> works properly?
>>
>> Thanks
>>
>>  Barry
>>
>>>
>>
>>
>
>
>
> -- 
> 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
>