What is the intended behavior of PetscDLSym when called on an empty handle: PetscDLSym(handle=PETSC_NULL, symbol, &value) My understanding was that this should look for symbol in the symbol table of the main executable. This is based on what happens in the Windows case (#ifdef PETSC_HAVE_WINDOWS_H), but when using dlopen (#ifdef PETSC_HAVE_DLFCN_H), this probably won't behave correctly,as currently implemented. This is because the above call will boil down to value = dlsym((dlhandle_t)0, symbol), which on many systems returns NULL (e.g., on Ubuntu 9.10). There is a relatively easy fix, which is to obtain the handle of the main executable with, for example, dlhandle = dlopen(0,RTLD_LOCAL|RTLD_LAZY) followed by value = dlsym(dlhandle,symbol)
I have played around with it on my box, and it appears to work. I can push that fix, if that's what we decide we want, and if it doesn't alter the currently expected behavior. There is one caveat: symbols can be dlsym'ed from the executable only if they are exported as dynamically-loadable, which is not the default behavior for linking executable (so as not to pollute the dynamic symbol table). 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. Incidentally, currently there appears to be no way to supply additional linker flags, as used to be the case with LDFLAGS. Dmitry. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100805/ba455026/attachment.html>
