What is the intended behavior of PetscDLSym when called on an empty handle: PetscDLSym(handle=PETSC_NULL, symbol, &value)<br>My understanding was that this should look for symbol in the symbol table of the main executable.<br>
This is based on what happens in the Windows case (#ifdef PETSC_HAVE_WINDOWS_H), <br>but when using dlopen (#ifdef PETSC_HAVE_DLFCN_H), this probably won't behave correctly,as currently implemented.  <br>This is because the above call will boil down to <br>
   value = dlsym((dlhandle_t)0, symbol), <br>which on many systems returns NULL (e.g., on Ubuntu 9.10).<br>There is a relatively easy fix, which is to obtain the handle of the main executable with, for example,<br>  dlhandle = dlopen(0,RTLD_LOCAL|RTLD_LAZY)<br>
followed by<br>  value = dlsym(dlhandle,symbol)<br><br>I have played around with it on my box, and it appears to work.<br>I can push that fix, if that's what we decide we want, and if it doesn't alter the currently expected behavior.<br>
There is one caveat: symbols can be dlsym'ed from the executable only if they are exported as dynamically-loadable,<br>which is not the default behavior for linking executable (so as not to pollute the dynamic symbol table).<br>
On linux the linker needs to get -Wl,--export-dynamic, but it would be nice to enable some sort of portable option at compile time.<br>Incidentally, currently there appears to be no way to supply additional linker flags, as used to be the case with LDFLAGS.<br>
<br>Dmitry.<br>