[petsc-dev] PetscDLSym called on an empty handle

[Dmitry Karpeev]

On Thu, Aug 5, 2010 at 11:53 AM, Matthew Knepley <knepley at gmail.com> wrote:

> On Thu, Aug 5, 2010 at 11:47 AM, Dmitry Karpeev <karpeev at mcs.anl.gov>wrote:
>
>> On Thu, Aug 5, 2010 at 11:42 AM, Matthew Knepley <knepley at gmail.com>wrote:
>>
>>> 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.
>>>
>>
> Whoops this is wrong. Its something different.
>
>
>>
>>>
>> Sorry, I meant configure-time option.
>>
>
> Yes, it should be a configure option.
>

Actually, I'm guessing that there should be a configure-time option to
figure out the platform-dependent
way of exporting symbols as dynamic, and then a compile-time option to
actually export the executable's symbols.
(Not everybody may want to pollute the dynamic symbol table and,
potentially, increase the required symbol search
time).

Dmitry.

>
>
>> Does sharedLinkerFlags alter the behavior of CLINKER?
>>
>
> I thought we fixed LDFLAGS, but maybe not.
>
>   Matt
>
>
>> Unless there is another way to link an executable.
>>
>> Dmitry.
>>
>>
>>>
>>>   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
>>>
>>
>>
>
>
> --
> 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/d57be3d3/attachment.html>