<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 6, 2013 at 5:58 AM, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>The whole idea of compiler flags is that the compiler understands them. I think its a bad model to have</div><div>
flags that might work on one file and not another. That just seems like a nightmare.</div></blockquote><div><br></div><div style>-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.</div>
<div style><br></div><div style>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div></div><div>If there really are compiler flags that can break projects, they should be removed from compilerOptions.py, and</div>
<div>put directly in PETSc/Configure.py and added into the output in Dump().</div>
<div></div></blockquote></div><br>There is no way to test it from BuildSystem without affecting the way all packages are built?</div><div class="gmail_extra"><br></div><div class="gmail_extra" style>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).</div>
</div>