Hi Jed, The latest patch causes a symbol re-definition error in: petsc-dev / src / ksp / pc / impls / gamg / gamg.h and petsc-dev / src / ksp / pc / impls / gamg / gamg.c
for the logging events. Do you still need the definitions in gamg.c? Thanks, Garnet On Tue, Mar 5, 2013 at 9:09 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote: > If you configure --with-visibility, PETSc will compile with > -fvisibility=hidden so that any symbols that are _not_ declared with extern > or PETSC_EXTERN will become local to the file. Unfortunately, when configure > --with-clanguage=C++ --with-c-support, these internal symbols will have > their names mangled and will expect function pointers to _not_ be extern "C" > (unless using an extern "C" typedef). This is a relatively minor issue, but > I would like to be more precise about what symbols we wish to be accessible. > Note that anything that we want to be directly referenced by a plugin must > be PETSC_EXTERN. This means that most functions in include/petsc-private > should be PETSC_EXTERN, even though we don't expect normal users to call > them. > > I just pushed a couple patches that add PETSC_INTERN and PETSC_INTERN_C (to > be used when you always need an extern "C" interface) and applied the rule > to a bunch of the src/**/*impl.h declarations. This reduces the number of > exported symbols by a factor of 2, speeding up dispatch (no more calling > through the PLT), allowing more shared-library code to be shared between > multiple processes (important when running many MPI processes on > small-memory nodes), and reducing linking and loading time. > > There are still more places that we could tighten up, but we probably need > to refine our concept of which symbols are meant to be directly addressable > from outside PETSc. Anyway, the initial guidelines from > https://bitbucket.org/petsc/petsc-dev/commits/8413f6e91807356123f19f648513e17d0ebc6e4e > are > > PETSC_INTERN is for symbols that are shared between files, but only used > within one shared library. Note that PETSC_EXTERN must be used for symbols > that are accessed from other shared libraries (e.g., a symbol in petscmat.so > that is accessed from petscksp.so). > > 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. -- Regards, Garnet
