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>

Reply via email to