<div dir="ltr">On Tue, Feb 5, 2013 at 8:42 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"><div class="im"><br><div class="gmail_quote">On Tue, Feb 5, 2013 at 7:32 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>   4. XXIntializePackage() is called automatically for all default PETSc classes when using --with-single-library=1</div>

<div><br></div><div>I am guessing that default call will use PETSC_COMM_WORLD.</div></blockquote></div><br></div>One way to do this is to make a "constructor" function for each shared library that registers its *InitializePackage function to be called from PetscInitialize. (Constructors are called before main so they can't be collective.) Then we wouldn't have a source-level reverse dependency and it would get loaded even for single-library=0. I'm not aware of any platforms that don't support some constructor mechanism, either via an attribute or C++ (which should not require linking libstdc++).</div>

</div>
</blockquote></div><br><div style>It sounds like the most likely thing to break on porting, however its exactly what we have for dynamic libraries.</div><div style><br></div><div style>   Matt</div><div style><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>