On Thu, Aug 5, 2010 at 11:40 AM, Dmitry Karpeev <karpeev at mcs.anl.gov> wrote:
> 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. > This is sharedLinkerFlags. Matt > Incidentally, currently there appears to be no way to supply additional > linker flags, as used to be the case with LDFLAGS. > > Dmitry. -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100805/659a4d9d/attachment.html>