I'm going to work on PETSc's dynamic libraries support

[Barry Smith]

On Oct 17, 2008, at 2:01 PM, Lisandro Dalcin wrote:

> After the discussion about mapping cookies to Python types (let's
> continue on int in the near future), I realized that petsc4py was
> actually broken in for the case of PETSc's configure.py
> --with-dynamic=1 !!!. Of couse, I've finally fixed all the problems,
> now petsc4py can be built and used with any of static/shared/dynamic;
> of course, in the static case, things get more restrictive (for
> example, now easy way to use petsc4py+slepc4py+tao4py), so the
> recommended way is to use at least shared libs.
>
> After all that work, I've started to dive in the whole beast in PETSc
> core, and I believe there is a lot of room for improvement.  So I'll
> take this. Could someone of you wipe-out this repo and make in that
> directory a fresh clone of petsc-dev?
>
> http://petsc.cs.iit.edu/petsc/petsc-dev-dalcinl/
>
>
> Now, the stuff I'm thinking we can improve:
>
> 1) Make a distintion between PETSC_USE_DYNAMIC_LIBRARIES (ie, PETSc
> libs are intended to be dlopenable), and PETSC_HAVE_DYNAMIC_LIBRARIES
> (PETSc libs are just static/shared, not intended for dlopen; but PETSc
> CAN dlopen other  third-party libs).

Seems ok.
>
>
> 2) Add appropriate typedefs for PestcDLHandle, an enumeration
> PetscDLFlags, and routines PetscDLOpen, PetscDLClose, and PetscDLSym.
> This would abstract the handling of the different dlopen-like family
> of functions across platforms, in a way similar to what GNU libtool
> does.

    I worry that dlopen()/dlsym() may not be the right level of  
abstraction to
match (for example the Windows approach) a general idea of "dynamic"  
libraries.
Especially dlsym().

   I guess it is ok to add them, but I hate to add stuff, you know.

>
>
> 3) The above support for dlopening other libs will be available in
> regardeless of PETSc libraries being static/shared/dynamic. The only
> requisite for this to work is that
> dlopen/LoadLibrary/other-dlopen-like-api is available. For all this,
> perhaps I will need help for fixing BuildSystem in case this is
> necessary.

This is fine.
>
>
> 4) And finally, try to use all the above stuff tome make possible
> PETSc can dlopen the Python shared library and 'import' petsc4py.
> Working harder, all this could even work with PETSc static libs, more
> or less like you can build python with static libs, but the python
> executable can still dlopen extension modules.
>
> Now, I want to know your opinions...
>
>
> -- 
> 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
>