<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 23, 2013 at 10:51 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">>   We currently have -dll_pre/append PetscDLLibraryPre/Append() allowing users to indicate libraries to open. We don't have a concept of a path of directories to look for libraries. Conceivably we could introduce a path and only march through the path opening each library if the requested type is not found yet. This would mean in the "smallest change from current source code" implementation that whenever PetscFunctionListFind() (for types) does not find a request it opens the next library and then looks again. One issue for that is if the PetscFunctionListFind() is not run on PETSC_COMM_WORLD, some processes will open more libraries than others; this makes the "search through the path only as needed" a dangerous thing due to the parallelism. I'd be inclined to just open all the dynamic libraries in PetscInitialize() and tell people for performance reasons they may want to limit the path for "big runs".<br>

><br>
<br>
</div>    Since we won't be searching through the libraries for symbols we can get rid of the prepend,append stuff as well and just have a command line option for opening libraries.</blockquote></div><div class="gmail_extra">
<br></div><div class="gmail_extra" style>Yup, sounds good. I don't like searching because of the collective load problem.</div><br>We could add PetscDLLibraryOpenTree() that would recursively open subdirectories and load all the shared libraries. This would let an application selectively load any plugins they were interested in as automatically as possible.</div>
</div>