<div dir="ltr">On Wed, Mar 6, 2013 at 7:49 AM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><div class="im">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><div>-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><br></div><div>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 class="im">
<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></div><br>There is no way to test it from BuildSystem without affecting the way all packages are built?</div></div></blockquote><div><br></div><div style>This is not about testing at all, its about using. You explicitly stick it in CFLAGS.</div>
<div style><br></div><div style>   Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">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>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener
</div></div>