[petsc-dev] PetscDLSym called on an empty handle

Matthew Knepley knepley at gmail.com
Thu Aug 5 11:53:16 CDT 2010


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.


> 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/62f48846/attachment.html>


More information about the petsc-dev mailing list