[petsc-dev] meaning of PETSC_USE_EXTERN_CXX?

[Jed Brown]

On Wed, Mar 6, 2013 at 5:58 AM, Matthew Knepley <knepley at gmail.com> wrote:

> The whole idea of compiler flags is that the compiler understands them. I
> think its a bad model to have
> flags that might work on one file and not another. That just seems like a
> nightmare.
>

-fvisibility=hidden causes functions to be hidden by default unless (a)
they are explicitly 'extern' or (b) their visibility is set explicitly.
This is like the Windows default so it's not exactly esoteric, but most
packages will not build shared libraries correctly with this flag.

Note that Open MPI sets visibility=hidden by default on systems that
support it. Now that we have PETSC_INTERN, we have an explicit way of
stating when symbols are meant to be internal to PETSc. If every function
in PETSc uses either PETSC_EXTERN, PETSC_INTERN, or static, then
-fvisibility=hidden will not change anything so we could skip it.


> If there really are compiler flags that can break projects, they should be
> removed from compilerOptions.py, and
> put directly in PETSc/Configure.py and added into the output in Dump().
>

There is no way to test it from BuildSystem without affecting the way all
packages are built?

The visibility macros also should not be used when building user code (like
examples) because we don't want to enforce the same discipline on them.
Maybe we should test for visibility so that
__attribute__((visibility("hidden"))) can be used, but leave off the
compiler flag (except for developer builds to enforce that all exports are
explicit---anything that fails will also fail on Windows).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130306/d99f3f42/attachment.html>