[petsc-dev] PetscDLSym called on an empty handle

[Matthew Knepley]

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>