[petsc-dev] Internal and external symbols

[Jed Brown]

On Tue, Mar 5, 2013 at 5:21 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>   Please don't make any other changes along this line for right now. I
> have to merge my changes (removal/improvement of EXTERN_C_BEGIN/END)
> everywhere and test on many combinations of c/c++, dynamic, split libraries
> and push before you can make more changes.  It is a little hairy.
>

Sure, push to a private branch if you want help merging.


> On Mar 5, 2013, at 11:09 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>
> >
> > PETSC_INTERN_C is for functions with internal visibility that must use
> the `extern "C"` calling convention. Normally this is any symbol passed to
> a dynamic registration function.
>
>     At times I've wanted to split the PETSc library into two (or more)
> parts. The "interface" library, that contains functions users call directly
> like KSPSetType(), KSPGMRESSetRestart() and the actual implementations,
> like KPSCreate_GMRES(), KSPGMRESSetRestart_GMRES(), these would be loaded
> dynamically.  Hence I've kept the dynamic registration functions as
> PETSC_EXTERN_C, not PETSC_INTERN_C.   This "may" be a way to handle
> different precisions, complexity in the same application also if we can
> figure out how to put each implementation (for different precision,
> complexity) in a separate dynamically loaded library and load several at a
> time (without symbol conflict).
>

Sure, that's an interesting direction. There are still quite a few
interface functions that pass scalars along and I don't see a clean
resolution to that part, but this direction is good to keep in mind. That
said, it would be pretty easy to batch-change PETSC_INTERN_C .* XCreate_Y
instances to PETSC_EXTERN_C.

We don't have the Windows Problem (need for long-term binary stability when
users abuse private interfaces) so I'm not worried about having a few
private functions that users shouldn't call, but that still have exported
symbols. I put in PETSC_INTERN* because cutting the number of exported
symbols in half seemed substantial enough.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130305/a973d40f/attachment.html>